Identity-Led Deception for Cloud Credential Compromise

The short version

Identity-led deception is useful because cloud credential attacks are often fast, low-noise, and hard to distinguish from normal administration. Decoys create high-confidence tripwires around the exact behaviour defenders care about:

• someone opened decoy material, such as a document, ticket, or file, that appears to contain credentials;
• someone tested a cloud key, API token, SaaS sign-in, service principal, or OAuth credential;
• someone attempted to enumerate a cloud environment using credentials that should never be used;
• someone accessed a document, export path, or sensitive-looking resource that has no legitimate business purpose;
• automation, offensive tooling, malware, an AI agent, or an insider account touched a decoy while searching for secrets.

Each of these is evidence worth investigating rather than proof of malicious intent. An approved scanner, test, or AI agent doing authorised work can also touch a decoy, so the significance of a trigger depends on placement, expected automation, and the actor’s authorised activity.

This guide uses the term decoy. It is broader than “honeypot” or “canary” and aligns with MITRE D3FEND’s language around Decoy Object, Decoy File, Decoy Session Token, Decoy Persona, Decoy User Credential, and Decoy Network Resource.¹²

Thinkst Canarytokens are a strong example of the tripwire pattern. Thinkst describes Canarytokens as digital tripwires that can be deployed in documents, web bugs, API keys, VPN profiles, QR codes, AWS API keys, S3 buckets, Azure login certificates, Office 365 mail bugs, Google Docs/Sheets, and other locations. Its AWS API Key Canarytoken is designed to look like cloud credentials and alert when the key is used through the AWS API.³⁴

Identity-led deception applies the same idea at a broader architectural layer: decoy credentials, personas, documents, access paths, cloud resources, and workflows working together as an early-warning mesh around identity and cloud control planes.

Why cloud credentials are so dangerous

Cloud credentials are powerful because they compress identity, permission, and access into portable tokens. They are also easy to mishandle.

A credential might appear in:

• a .env file;
• a Git repository or commit history;
• a CI/CD environment variable;
• a build log;
• a container image;
• a Terraform state file;
• a developer laptop;
• a browser credential store;
• a password manager;
• a cloud metadata service;
• a Jira ticket or Confluence page;
• a Slack or Teams message;
• a Microsoft 365 document;
• a backup archive;
• a SaaS integration config;
• an AI agent or MCP configuration file;
• a non-production tenant that no one has reviewed recently.

MITRE ATT&CK explicitly captures this problem. Unsecured Credentials (T1552) includes credentials in files, shell history, private keys, cloud instance metadata APIs, container APIs, and chat messages.⁵ Credentials from Password Stores (T1555) includes web browsers, password managers, and cloud secrets management stores.⁶ Steal Application Access Token (T1528) covers tokens used for cloud, SaaS, container, and CI/CD access.⁷

Once a valid credential is found, the adversary does not need to exploit a vulnerability. They can often authenticate like a user, service, build job, or application.

That is why credential compromise is such a strong use case for deception: if adversaries are already hunting for credentials, defenders should plant safe, high-confidence credentials that are valuable only as sensors.

How adversaries discover cloud credentials

Adversaries and red teams do not need exotic methods to find cloud credentials. Many exposures are discovered through ordinary search, standard tooling, and basic cloud enumeration.

GitHub secret scanning exists because secrets in repositories are a common and serious problem. GitHub says secret scanning detects API keys, passwords, tokens, and other secrets in repositories, and can scan Git history, issues, pull requests, discussions, wikis, and gists depending on repository type and configuration.⁸

The scale is also large. GitGuardian’s 2026 State of Secrets Sprawl research reported continued growth in exposed secrets, with internal repositories substantially more likely than public repositories to contain hardcoded secrets and a meaningful share of leaks originating outside source code in collaboration and productivity tools.⁹ Its 2025 report found 23.8 million new secrets leaked on public GitHub repositories in 2024, a 25% year-over-year increase, and reported that many leaked secrets remained valid years after exposure.¹⁰

The lesson is simple: credentials are easy to find because teams create, copy, store, and forget them in many places.

Real incidents show the pattern

The following incidents are useful because they are not just theoretical. They show how cloud credential exposure, SaaS credential reuse, non-production identity gaps, and CI/CD secrets can lead to major security events.

Capital One, 2019: cloud role credentials through metadata access

Capital One disclosed in July 2019 that an outside individual gained unauthorised access to certain personal information about approximately 100 million people in the United States and approximately 6 million people in Canada.¹¹

The widely discussed technical lesson from the incident is that a cloud-side configuration issue and server-side request forgery path allowed access to AWS role credentials through the instance metadata service, which were then used to reach S3 data. Post-incident technical analyses describe the chain as SSRF to metadata credentials to S3 enumeration and data access.¹² AWS has since moved EC2 towards IMDSv2, which is designed to blunt this class of SSRF-based metadata abuse: newly released instance types, Amazon Linux 2023, and console Quick Start launches now use IMDSv2 only by default.¹³

Why this matters for deception: cloud role credentials are valuable because they are trusted by design. If an adversary can obtain them, the next step is usually to test what they can do.

Decoy lesson: place monitored decoy credentials, decoy roles, and decoy cloud paths where an adversary exploiting metadata, application, or workload access would expect to find something useful. Alerts should trigger when a decoy credential is tested or used, and when decoy S3 prefixes or export paths are accessed.

Uber, 2014 and 2016: AWS credentials in code repositories

The FTC’s Uber complaint described cloud security failures around access keys, MFA, access control, and monitoring. The FTC wrote that in May 2014 an intruder used an access key that an Uber engineer had publicly posted on a code-sharing site to access data in Uber’s cloud storage service.¹⁴

The later 2016 Uber breach also involved adversaries finding credentials associated with cloud storage after gaining access to private code repositories, according to public reporting and subsequent legal history.¹⁵

Why this matters for deception: adversaries search code repositories because credentials there are often real, long-lived, and over-permissioned.

Decoy lesson: internal repositories, legacy branches, infrastructure examples, and developer onboarding materials are natural places for decoy cloud credentials. Each credential should be unique to its placement, have no production access, and trigger an alert if used.

Codecov, 2021: CI/CD environment variables and secrets

Codecov’s April 2021 post-mortem said a malicious change to its Bash Uploader extracted git remote origin URLs and environment variables from customer CI environments where the uploader ran. The incident was detected after a customer performing SHASUM checking noticed a discrepancy and reported it.¹⁶

Why this matters for deception: CI/CD environments often contain exactly what adversaries want: deployment credentials, package tokens, cloud keys, signing keys, and environment variables.

Decoy lesson: build systems should contain instrumented decoy secrets that are safe to expose but noisy when used. If a CI/CD compromise exfiltrates environment variables, the decoys should be among the secrets an adversary tests.

CircleCI, 2023: session theft and customer environment variables

CircleCI’s January 2023 incident report said an unauthorised third party deployed malware to a CircleCI engineer’s laptop, stole a valid two-factor-backed SSO session, escalated access to a subset of production systems, and exfiltrated customer environment variables, tokens, and keys. CircleCI also said it worked with AWS to notify customers whose AWS tokens may have been impacted.¹⁷

Why this matters for deception: MFA is critical, but session theft can bypass the point where MFA was originally satisfied. Once inside a trusted platform, adversaries may reach stored secrets.

Decoy lesson: CI/CD contexts, project variables, and build credentials should include decoy values that generate immediate alerts if tested outside expected workflows.

Microsoft Midnight Blizzard, 2024: non-production identity and OAuth abuse

Microsoft reported that Midnight Blizzard used password spraying to compromise a legacy, non-production test tenant account that did not have MFA enabled. Microsoft also described malicious use of OAuth applications, including compromise of a legacy test OAuth application with elevated access and subsequent access to Exchange Online mailboxes.¹⁸

Why this matters for deception: stale identities, legacy tenants, test apps, and OAuth consent paths can create real risk even when they are not part of the production story everyone watches.

Decoy lesson: non-production tenants, service principals, OAuth apps, and identity references should contain decoys. A sign-in attempt or other interaction with a decoy non-production identity or app can reveal reconnaissance before an adversary reaches more important accounts.

Snowflake customer attacks, 2024: stolen SaaS credentials and no MFA

Mandiant reported that UNC5537 systematically compromised Snowflake customer instances using stolen customer credentials, with credentials primarily obtained from infostealer malware campaigns on non-Snowflake systems. Mandiant stated that incidents were traced to compromised customer credentials rather than a breach of Snowflake’s enterprise environment, and identified factors such as lack of MFA and network allow lists in successful compromises.¹⁹

Why this matters for deception: SaaS credentials are cloud credentials too. Data platforms, analytics tools, and cloud warehouses are high-value targets because they centralise business data.

Decoy lesson: create decoy SaaS accounts, decoy API tokens, decoy data warehouse connection strings, and decoy export workflows that cannot access real data but alert if tested.

Why decoys are especially strong for cloud credential compromise

Traditional anomaly detection is useful, but it has to answer hard questions:

• Is this sign-in unusual enough?
• Is this API call suspicious or just administration?
• Is this location abnormal or just remote work?
• Is this tool usage hostile or legitimate DevOps?
• Is this service account behaviour new or merely undocumented?

Decoys answer a simpler question:

Did anyone interact with something that should have no legitimate interaction at all?

That creates a much cleaner signal.

A decoy credential does not need to predict every adversary behaviour. It only needs to be credible enough that a credential hunter, adversary, rogue automation, insider, or AI agent might collect and test it.

MITRE alignment

MITRE Engage

MITRE Engage is a framework for discussing and planning adversary engagement, deception, and denial activities. MITRE describes Engage as a way for defenders, vendors, and decision makers to plan adversary engagement activities, with a focus on driving up the cost and driving down the value of adversary operations.²⁰

Engage is useful here because credential decoys should not be placed at random. They should be planned around a clear objective.

A cloud credential deception program can map to MITRE Engage like this:

MITRE Engage is also important for language discipline. This is not hack-back. It is controlled adversary engagement inside the defender’s environment, with defined guardrails.

MITRE D3FEND

MITRE D3FEND is the best fit for FIRCY’s preference for decoys. D3FEND defines a Decoy Object (D3-DO) as an object created and deployed for the purpose of deceiving attackers. Its technique overview says decoy objects typically have detectable means of communication, no legitimate business purpose, and should be logged and analysed when touched.¹

Relevant D3FEND concepts include:

This is why “decoy credential” is stronger than “canary token” as the main category. A canary token is a useful mechanism. A decoy is the broader defensive object and architecture.

MITRE ATT&CK

Credential deception also maps to several ATT&CK behaviours defenders already track:

A good decoy strategy does not replace ATT&CK-informed monitoring. It gives defenders cleaner signals inside these behaviours.

The tools that make credential discovery easy

The point of this section is not to teach adversaries. It is to explain why defenders should assume that exposed credentials will be found quickly.

Secret scanning tools

Tools such as GitHub secret scanning, Gitleaks, TruffleHog, GitGuardian, and similar scanners can identify hardcoded credentials in repositories, histories, and artefacts. These tools are valuable for defenders, but adversaries can use the same general technique: search broadly, validate what looks real, then use what works.

GitHub secret scanning scans repositories and related collaboration areas for known secret formats and alerts when supported secrets are found.⁸ Gitleaks describes itself as a SAST tool for detecting and preventing hardcoded secrets such as passwords, API keys, and tokens in Git repositories.²⁵ TruffleHog is widely used to find leaked secrets and has been catalogued by MITRE ATT&CK as software capable of gathering access tokens and API tokens from CI/CD pipelines and repositories.⁷

Cloud enumeration and attack-path tools

Once a cloud credential works, the next step is usually enumeration.

MITRE ATT&CK’s Account Discovery: Cloud Account (T1087.004) page notes that AWS CLI, Azure CLI, and GCP CLI can be used with authenticated access to enumerate users, roles, and service accounts. It also references tools such as Pacu, ROADTools, AADInternals, and AzureHound in the context of cloud account discovery.²¹

Pacu is an open-source AWS exploitation framework designed for offensive security testing against AWS environments. Rhino Security Labs describes it as a post-compromise framework with modules for enumeration, privilege escalation, persistence, data exfiltration, and logging disruption.²⁶

CloudFox is an open-source tool from Bishop Fox designed to help penetration testers and security professionals find exploitable attack paths in cloud infrastructure. Its documentation says it helps answer questions such as what secrets are in EC2 user data or environment variables, what workloads have administrative permissions, and what principals can do.²⁷

AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure AD / Entra ID, and MITRE ATT&CK lists it as software capable of enumerating Azure AD users.²⁸

The defensive takeaway is straightforward: once a credential is found, tooling can make the next steps fast. Decoy credentials give defenders a way to see the moment a found credential is put to use.

What “zero risk” should mean

Strictly speaking, no deployed security control is literally zero risk. A more accurate phrase is:

zero standing privilege, zero production access, and near-zero operational risk.

That said, credential decoys can be designed so they create no meaningful access path to production systems.

The safe design goal is:

An adversary can discover, copy, test, and attempt to use the decoy, but the decoy cannot grant access to production data, production systems, production identities, or production trust paths.

The zero-production-access model

A mature decoy credential program should follow these guardrails:

FIRCY decoy credentials follow this model: they are designed to be used at scale with zero production access and zero standing privilege. They are detection objects, not access objects.

Decoy credential design patterns

Pattern 1: Decoy AWS access keys

Use case: detect when an adversary, malware, insider, AI agent, or automated scanner tests or uses AWS-looking credentials.

Where to place:

• internal repositories;
• developer workstations;
• decoy .aws/credentials files;
• CI/CD project variables;
• build artefacts;
• synthetic runbooks;
• Microsoft 365 documents;
• Jira or Confluence pages;
• S3 export instructions;
• decoy integration config files.

Safe design:

• keep decoys isolated from production accounts;
• attach no production trust relationships;
• create credentials with no useful privileges, or only tightly constrained access to decoy-only resources;
• use explicit deny controls, permissions boundaries, and service control policies where appropriate;
• log management events with CloudTrail;
• route events through EventBridge, SIEM, SOAR, ticketing, Slack, Teams, email, or FIRCY.

AWS CloudTrail data events can record S3 object-level activity such as GetObject, DeleteObject, and PutObject, but AWS notes that data events are not logged by default and can be high volume, so plan data-event coverage around the protected data paths rather than assuming the default trail records it.²⁹

AWS GuardDuty also has finding types for EC2 instance credentials used from outside AWS or from another AWS account, which is relevant to credential exfiltration detection.³⁰

Thinkst’s AWS API Key Canarytoken is another practical version of this pattern: the generated AWS-looking credentials can be placed in private repositories or developer machines, and an alert is generated if they are used via the AWS API.⁴

Pattern 2: Decoy Entra ID users and service principals

Use case: detect attempts to use synthetic identities, service principals, OAuth references, admin-looking groups, or non-production identity paths.

Where to place:

• onboarding documents;
• architecture diagrams;
• internal runbooks;
• support tickets;
• privileged access notes;
• decoy app registration documentation;
• Microsoft 365 decoy files;
• developer wiki pages;
• cloud migration plans.

Safe design:

• decoy users should have no production roles;
• service principals should not have useful app permissions;
• decoy credentials should not reach real resources, while still producing useful sign-in telemetry;
• sign-in attempts should generate Entra sign-in logs;
• suspicious consent attempts and app changes should be monitored.

Microsoft’s Midnight Blizzard report shows why this matters: a non-production test tenant account without MFA and OAuth application abuse were part of the intrusion path.¹⁸

Thinkst’s Azure Entra ID Login Canarytoken is a related idea at the phishing layer. It uses CSS in Entra company branding to alert when a cloned Entra login page is accessed, helping identify adversary-in-the-middle phishing activity.³¹

Pattern 3: Decoy SaaS credentials

Use case: detect adversaries testing credentials for cloud data warehouses, CRM, support systems, code hosting, identity platforms, or productivity suites.

Examples:

• Snowflake connection strings;
• GitHub tokens;
• Slack app tokens;
• Salesforce API tokens;
• Okta app references;
• Google Workspace credentials;
• Microsoft Graph app secrets;
• data export API keys.

Safe design:

• credentials should not grant access to a real tenant, account, or production identity;
• no real customer, employee, or production data should be reachable;
• decoy credentials should generate an alert on sign-in attempt, API call, token validation, or network access;
• failed attempts should be treated as valuable, not ignored.

The Snowflake campaign is a strong example of why SaaS credential decoys matter. Mandiant reported that UNC5537 used stolen customer credentials, many from infostealer malware, to access customer Snowflake instances and exfiltrate data.¹⁹

Pattern 4: Decoy CI/CD secrets

Use case: detect build-system compromise, supply chain compromise, or unauthorised secret access.

Where to place:

• project-level CI variables;
• organisation-level contexts;
• decoy deploy jobs;
• build logs designed to look useful but remain safe;
• infrastructure-as-code examples;
• synthetic package publishing tokens;
• decoy container registry credentials.

Safe design:

• no production deployment permission;
• no package publish rights;
• no real signing capability;
• no ability to read real secrets;
• decoy values uniquely tied to project, branch, and build context;
• short lifecycle and automated rotation.

Codecov and CircleCI show why CI/CD is a priority surface. Codecov’s malicious uploader extracted environment variables, while CircleCI’s incident involved exfiltration of customer environment variables, tokens, and keys.¹⁶¹⁷

Pattern 5: Decoy documents and collaboration artefacts

Use case: detect humans, malware, agents, or adversaries reading sensitive-looking documents and support material.

Examples:

• access notes for a cloud export or backup workflow;
• data export runbooks;
• emergency or break-glass access procedures;
• service principal or admin account references;
• customer data export process documents;
• storage access notes marked as restricted.

Safe design:

• documents contain decoy keys, unique links, embedded beacons, decoy service references, or decoy access paths;
• all data is synthetic;
• every document has one unique token per placement;
• legitimate staff are briefed or access-controlled depending on governance requirements;
• alerts identify the source document and placement.

This pattern is especially relevant for insider threat and AI-agent misuse because documents, tickets, and collaboration pages are often the first place people or agents search for “how things work”.

Pattern 6: Decoy cloud resources and export paths

Use case: detect data theft staging, cloud reconnaissance, and export workflow abuse.

Examples:

• decoy S3 buckets or prefixes;
• decoy data export paths;
• synthetic customer records;
• synthetic operational reports;
• synthetic billing exports;
• synthetic analytics outputs;
• decoy database tables;
• decoy storage accounts;
• decoy service endpoints.

Safe design:

• resources are isolated from production;
• names are realistic but not confusing to operations;
• data is synthetic;
• object access is logged;
• every resource maps to a specific detection storyline;
• high-confidence activity routes to the existing incident workflow.

These patterns work well together: identity as the control plane, Microsoft 365 as the collaboration and document surface, and AWS or custom applications as the data and export surface.

How to deploy credential decoys at scale

The biggest mistake is to hand-place a few random decoys and forget them.

A scalable program needs inventory, uniqueness, ownership, metadata, telemetry, and lifecycle management.

Step 1: Define the detection objective

Start with one storyline, not everything.

Examples:

• detect cloud data export reconnaissance;
• detect stolen AWS keys from developer machines;
• detect SaaS credential testing from infostealer logs;
• detect CI/CD secret exfiltration;
• detect attempted use of decoy Entra ID service principals;
• detect insider access to sensitive IP documents;
• detect AI agent access to credentials in workspace files.

Good objective:

Detect use of synthetic AWS and SaaS credentials planted in developer, document, and CI/CD locations associated with customer analytics export workflows.

Bad objective:

Deploy deception everywhere.

Step 2: Create a decoy inventory

Every decoy should have metadata.

Recommended fields:

Step 3: Generate unique decoys per placement

Never reuse the same decoy credential in multiple places unless reuse is part of a deliberate test.

Unique placement is what turns an alert into a useful investigation:

• one key in one repository;
• one token in one document;
• one service principal reference in one runbook;
• one decoy Snowflake DSN in one support ticket;
• one AWS credentials file on one endpoint profile.

When the alert fires, you know where the credential was likely found.

Step 4: Use safe credential classes

At scale, not every decoy has to be a live cloud credential. Use the safest class that still creates the signal you need:

• callback-style tokens suit documents, tickets, and other places where an open or click is the signal;
• credential-style decoys suit places where you need to see validation or API use;
• whatever the class, confirm it cannot reach production data, identities, or trust paths before it is placed.

Step 5: Route alerts into existing workflows

A decoy alert should not live in a separate console that no one checks.

Route it to:

• SIEM;
• SOAR;
• EDR/XDR;
• ticketing;
• Slack;
• Microsoft Teams;
• email;
• case management;
• cloud-native event systems;
• FIRCY.

A good alert should include:

• decoy ID;
• credential type;
• placement location;
• source IP and ASN if available;
• user agent;
• cloud API or service attempted;
• identity context;
• document or repo path;
• timestamp;
• expected legitimate use;
• recommended response;
• confidence score.

Step 6: Classify severity by placement

Not every trigger means the same thing.

Step 7: Test the guardrails continuously

Every decoy credential should be tested before deployment:

• Can it access production? It should not.
• Can it assume a production role? It should not.
• Can it list real data? It should not.
• Can it create new credentials? It should not.
• Can it grant consent? It should not.
• Can it create cost? It should not.
• Does it alert when used? It must.
• Does the alert identify the placement? It must.
• Does the response workflow know what to do? It must.

Treat this as a safety control, not an afterthought.

Example pilot: identity-led cloud credential deception

A strong first pilot should be small, believable, and measurable.

Pilot objective

Detect attempted use of decoy credentials, and access to decoy documents, associated with a sensitive cloud data export workflow.

Pilot surfaces

• Entra ID identity references;
• Microsoft 365 documents;
• internal Git repository;
• CI/CD project variable;
• AWS (isolated from production);
• decoy S3 export path;
• SIEM or Teams alert routing.

Pilot artefacts

• one decoy Entra persona tied to analytics or platform administration;
• one decoy service principal reference;
• one decoy AWS credentials file;
• one Microsoft 365 document containing synthetic export instructions;
• one internal repository config file containing a unique decoy cloud key;
• one CI/CD context variable containing a unique decoy token;
• one decoy S3 prefix named like a sensitive export path;
• one alert playbook.

Pilot success criteria

• Every decoy has zero production access.
• Every decoy has a unique placement ID.
• Every decoy fires an alert when tested.
• Every alert routes to the existing workflow.
• The SOC can quickly identify the likely source location from the alert.
• The response team has a clear triage path.
• The pilot produces no operational disruption.

Response playbook

When a decoy credential fires, do not assume the answer immediately. Treat it as a high-confidence starting point.

First questions

1. Which decoy fired?
2. Where was it placed?
3. Who or what had access to that placement?
4. Was the trigger internal or external?
5. Was it a document open, DNS/HTTP beacon, sign-in attempt, API call, or cloud enumeration event?
6. Was the access tied to a real user, service account, endpoint, build job, or unknown source?
7. Was there recent activity around the placement, such as a repo clone, document access, ticket view, endpoint compromise, or CI/CD run?

Low-confidence response

Use when the trigger may be benign, such as a known scanner or expected test.

• open an investigation ticket;
• verify source;
• check recent legitimate activity;
• annotate the decoy inventory;
• tune allowlists only if justified.

Medium-confidence response

Use when the source is unknown or suspicious but not yet tied to impact.

• preserve logs;
• inspect identity sign-ins;
• review document/repo/ticket access;
• check endpoint telemetry;
• search for the decoy ID across logs;
• rotate nearby real credentials if exposure is plausible;
• notify asset owner.

High-confidence response

Use when the trigger suggests real compromise or external credential use.

• open an incident;
• isolate or investigate the source endpoint/account;
• revoke related sessions;
• rotate real credentials near the placement;
• review cloud/SaaS audit logs for adjacent activity;
• block source infrastructure if appropriate;
• preserve evidence for legal and forensic review;
• check whether the same actor touched other decoys.

Critical response

Use when the decoy was in a CI/CD, cloud export, identity, or data warehouse path and was tested externally or with suspicious automation.

• escalate to incident commander;
• freeze related deploy credentials;
• rotate high-risk keys;
• revoke active sessions;
• review cloud role assumptions and OAuth grants;
• inspect recent data export activity;
• apply containment through existing Microsoft/AWS/SaaS controls;
• communicate according to incident policy.

Common mistakes

Mistake 1: Giving decoys real access

A decoy credential should not be a weakly monitored real credential. It should be a detection object.

Mistake 2: Reusing the same decoy everywhere

Reuse creates confusion. Unique decoys provide attribution to a location.

Mistake 3: Deploying without legal and governance review

MITRE Engage starts with planning for a reason. Define guardrails, acceptable risk, and response rules before deployment.

Mistake 4: Forgetting the decoy lifecycle

Decoys that are not inventoried, reviewed, and retired become clutter.

Mistake 5: Making the decoy too obvious

fake-key-do-not-use.txt will not catch much. The decoy should look like the kind of mistake an adversary already expects to find.

Mistake 6: Making the decoy too perfect

A credential that looks more polished than the real environment can stand out. Believability comes from matching local naming, format, placement, and context.

Mistake 7: Over-automating response

A decoy alert is high-confidence, but automatic destructive containment can create operational risk. Start with alerting and analyst-guided response, then automate carefully.

Mistake 8: Ignoring failed attempts

A blocked sign-in, denied API call, or failed token validation may be the most valuable early signal.

Applying credential deception to AI-agent workflows

Credential misuse is not limited to a human operator. A controlled decoy can also provide an observation point when automation or an AI agent attempts to use it. Attribution and the meaning of the action still depend on the workflow and available evidence.

Read detecting rogue AI agents with cyber deception or see the AI-agent use case.

Where FIRCY fits

FIRCY Sense acts as an early-warning layer around identity and cloud access paths.

The core pattern is:

1. Use identity as the control plane.
2. Place decoy credentials, identities, service references, documents, and export paths where adversaries already search.
3. Ensure those decoys have no production access.
4. Capture any interaction as high-confidence telemetry.
5. Route the alert into existing workflows such as SIEM, SOAR, EDR, ticketing, Slack, Microsoft Teams, email, or custom APIs.
6. Use the alert to contain compromised identities, rotate nearby real credentials, and close the process gap that exposed the path.

Decoys do not replace IAM, MFA, EDR, CSPM, secret scanning, or cloud logging. The distinction is:

Secret scanning tells you where credentials may already be exposed. Identity-led deception tells you when someone has actually opened decoy material or tested or used a decoy credential.

That is the gap decoys fill.

How the pieces fit together

[Developer / Insider / Adversary / AI Agent]
          |
          v
[Repos] [Docs] [Tickets] [CI/CD] [Endpoints] [Cloud Metadata] [SaaS Config]
          |
          v
[Unique Decoy Credentials, Personas, Files, Tokens, Paths]
          |
          v
[FIRCY Sense detection + cloud and identity context]
          |
          v
[SIEM / SOAR / EDR / Ticketing / Teams / Slack / Email]
          |
          v
[Investigate, revoke sessions, rotate nearby real secrets, contain source]

Practical checklist

Strategy

• Define the crown-jewel identity and data paths.
• Choose one pilot storyline.
• Define the operational objective using MITRE Engage language.
• Define what counts as a high-confidence trigger.
• Agree legal, privacy, and HR guardrails.
• Document what decoys are not allowed to do.

Design

• Map decoy types to MITRE D3FEND concepts.
• Map likely adversary behaviours to MITRE ATT&CK.
• Use unique credentials per placement.
• Avoid production permissions.
• Keep decoys isolated from production accounts, tenants, and trust paths.
• Validate that every credential has zero production access.

Deployment

• Place decoys in repositories, documents, CI/CD, endpoints, cloud paths, and SaaS configs.
• Keep placements believable.
• Record every decoy in an inventory.
• Add metadata for owner, placement, expiry, and response playbook.
• Test every decoy before production rollout.

Telemetry

• Capture cloud API attempts.
• Capture identity sign-ins.
• Capture document opens or link beacons.
• Capture object access to decoy storage paths.
• Capture SaaS sign-in or token validation attempts.
• Route alerts into existing workflows.

Response

• Triage by placement and source.
• Correlate with identity, endpoint, repo, CI/CD, and SaaS logs.
• Rotate nearby real credentials if exposure is plausible.
• Revoke suspicious sessions.
• Investigate the system where the decoy was found.
• Feed lessons back into IAM, secret management, training, and architecture.

Recommended related FIRCY resources

• Detecting rogue AI agents with cyber deception
• Cyber deception readiness checklist
• Decoys vs honeypots vs honeytokens vs canary tokens
• FIRCY for AWS environments
• What is active defence in cyber security?

Source notes