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 found a credential in a repository, document, ticket, chat, build pipeline, endpoint, or cloud workload;
• someone tested a cloud key, API token, SaaS login, 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;
• someone is using automation, offensive tooling, malware, an AI agent, or an insider account to search for secrets.

For FIRCY, the preferred term is decoy. It is broader and cleaner than “honeypot” or “canary” because it 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.³⁴

FIRCY’s benefit is to describe and deliver this 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 includes credentials in files, shell history, private keys, cloud instance metadata APIs, container APIs, and chat messages.⁵ Credentials from Password Stores includes web browsers, password managers, and cloud secrets management stores.⁶ Steal Application Access Token covers tokens used for cloud, SaaS, container, and CI/CD access.⁷

Once a valid credential is found, the attacker 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 attackers are already hunting for credentials, defenders should plant safe, high-confidence credentials that are valuable only as sensors.

How attackers discover cloud credentials

Attackers 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 made IMDSv2, which is designed to blunt this class of SSRF-based metadata abuse, the default for new EC2 instances.¹³

Why this matters for deception: cloud role credentials are valuable because they are trusted by design. If an attacker 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 attacker exploiting metadata, application, or workload access would expect to find something useful. Alerts should trigger on credential testing, unexpected GetCallerIdentity-style validation, role use from unexpected infrastructure, and access to decoy S3 prefixes or export paths.

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 attackers 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: attackers 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 attackers 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 attacker 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, attackers 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 decoy non-production identity or app that is touched can reveal reconnaissance before an attacker 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 centralize 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 login 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 attacker behaviour. It only needs to be credible enough that a credential hunter, intruder, 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 treated as random traps. 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 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 attackers. 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 artifacts. These tools are valuable for defenders, but attackers 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 Cloud Account Discovery 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 that moment.

The right way to talk about “zero risk”

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 attacker 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:

This lets you say:

FIRCY decoy credentials 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 attacker, malware, insider, AI agent, or automated scanner discovers and tests AWS-looking credentials.

Where to place:

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

Safe design:

• use a dedicated decoy AWS account, not production;
• 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;
• consider targeted data events for decoy S3 objects or prefixes;
• 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 targeted selectors are important.²⁹

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;
• fake 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;
• credentials should be blocked, expired, or trapped depending on the telemetry goal;
• sign-in attempts should generate Entra sign-in logs;
• suspicious consent attempts and app changes should be monitored;
• conditional access should prevent actual access while preserving useful detection telemetry where possible.

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 attackers 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 point to a decoy tenant, decoy account, or blocked identity;
• no real customer, employee, or production data should be reachable;
• decoy credentials should generate an alert on login 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;
• organization-level contexts;
• fake deploy jobs;
• build logs designed to look useful but remain safe;
• infrastructure-as-code examples;
• synthetic package publishing tokens;
• fake 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 artifacts

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

Examples:

• AWS export credentials - analytics backup.md;
• OEM telemetry data export runbook.docx;
• Snowflake emergency access procedure.pdf;
• prod-admin-service-principal.txt;
• customer-data-export-process.xlsx;
• S3 bucket access notes - restricted.docx;
• M365 break-glass account procedure.md.

Safe design:

• documents contain decoy keys, unique links, embedded beacons, fake service references, or fake 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;
• fake fleet or device reports;
• fake billing exports;
• fake telemetry 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.

This is a strong FIRCY deployment pattern: use identity as the control plane, Microsoft 365 as a collaboration and document surface, and AWS/custom apps as the data/export surface.

How to deploy credential decoys at scale

The biggest mistake is to hand-place a few random traps 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 Entra ID service principal discovery;
• 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 fake 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.

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 discovery or use of decoy credentials 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 decoy account;
• decoy S3 export path;
• SIEM or Teams alert routing.

Pilot artifacts

• one decoy Entra persona tied to analytics or platform administration;
• one decoy service principal reference;
• one fake 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 identify the likely source location within one minute.
• 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, login 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 attacker 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 login, denied API call, or failed token validation may be the most valuable early signal.

Where FIRCY fits

FIRCY Sense can be positioned 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 attackers 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.

FIRCY should not claim that decoys replace IAM, MFA, EDR, CSPM, secret scanning, or cloud logging. The stronger claim is:

Secret scanning tells you where credentials may already be exposed. Identity-led deception tells you when a credential-shaped object has actually been discovered, tested, or used.

That is the gap decoys fill.

Suggested customer-facing architecture

[Developer / Insider / Attacker / AI Agent]
          |
          v
[Repos] [Docs] [Tickets] [CI/CD] [Endpoints] [Cloud Metadata] [SaaS Config]
          |
          v
[Unique Decoy Credentials, Personas, Files, Tokens, Paths]
          |
          v
[Zero-access / decoy-only cloud account, tenant, app, bucket, API, or callback]
          |
          v
[FIRCY Sense telemetry + cloud logs + identity logs]
          |
          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

• Use the term decoy as the umbrella category.
• Map decoy types to MITRE D3FEND concepts.
• Map likely attacker behaviours to MITRE ATT&CK.
• Use unique credentials per placement.
• Avoid production permissions.
• Use a dedicated deception account, tenant, or sandbox where practical.
• 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 login 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

• Cyber deception readiness checklist

More FIRCY deception guides are on the way, including decoys, honeypots, lures, and canaries; insider threat detection with decoys; using decoys to detect rogue AI agents; and deployment patterns for Microsoft 365, AWS export paths, and Entra ID.

Source notes