Definition
The RPA agent’s service account credentials (used to access databases, APIs, and financial systems) are accidentally exposed: committed to a public code repository, stored in an unprotected environment variable, or left in a container image layer. This is not a compromise of the agent itself; it is a deployment infrastructure vulnerability. The distinction from T3 Privilege Compromise is that T22 is about credential leakage rather than agent role misconfiguration.
What it looks like in practice
A developer commits the RPA agent’s service account key to a public GitHub repository as part of a configuration file. An automated secret-scanning tool or a manual attacker discovers the key within hours. The attacker uses it to connect directly to the company’s financial API, bypassing the agent and all of its policy controls, and exfiltrates or modifies financial records.
In a CI/CD variant, the key is stored as an unmasked pipeline variable and appears in build logs accessible to all project contributors, exposing it to insider threats as well as external observers of public pipeline logs.
Why it’s dangerous in multi-agent context
Agents require broad service account permissions to operate autonomously across multiple backend systems: email, financial APIs, audit logs, and databases. A single exposed credential therefore grants an attacker a large lateral surface, because every system the agent was authorised to access is now reachable directly. Because agents run continuously and their credentials are typically long-lived, the window of exposure before rotation is enforced may span days or weeks. Credential exposure also threatens multi-agent deployments where the same service account is shared across a fleet of agents.
Detection signals
Exposed service-account credentials are used directly against backend APIs from attacker-controlled infrastructure, producing authentication patterns that differ from the agent’s normal access profile.
- A successful API authentication using the agent’s service-account key from an IP address not in the agent host’s known egress range. Log source IP on every authentication event and alert on first-seen IP for a given key.
- A secrets-scanner (e.g.
git-secrets,trufflehog, or the GitHub secret-scanning feature) firing on a repository push containing a pattern matching a cloud-provider API key or a database connection string. Treat each hit as a confirmed exposure requiring immediate rotation. - Bulk read or write operations against the financial API outside of the agent’s normal operating hours (e.g. 03:00–05:00 local time) authenticated with the agent’s service-account key. Raise a time-of-day anomaly alert on financial API access logs.
- A CI/CD build log containing a string matching the pattern of a known secret format (AWS
AKIA…, GCPya29.…) visible in a job’s stdout. Instrument the pipeline to scan build log output and mask or alert on credential-shaped strings. - A credential rotation event not initiated by the secrets management system’s scheduled rotation (i.e. a manual API key creation or deletion outside the rotation window). Alert on any out-of-schedule IAM key lifecycle event for agent service accounts.
Mitigations
- Never commit secrets to version control; use a secrets management system (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) and inject credentials at runtime only.
- Rotate all service account credentials on a short schedule and invalidate immediately on suspected exposure.
- Enforce least-privilege: issue separate, scoped credentials for each backend system the agent accesses rather than a single broad-access key.
- Enable secrets-scanning in CI/CD pipelines and on repository push; configure alerts for detected credential patterns.
Relation to base threat (T1–T17)
T22 extends T3 Privilege Compromise. Where T3 addresses the agent’s own role or permission misconfiguration, T22 addresses the service account credentials the agent uses, which are leaked from the deployment layer rather than misconfigured within the agent. T34 (Wallet Key Compromise) is the blockchain-specific analogue: the same class of credential leakage but targeting an ElizaOS agent’s Solana wallet private key.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T22 is covered by the following Top 10 entries:
-
ASI03 Identity & Privilege Abuse primary When an agent acts on a user's behalf it inherits that user's credentials and permissions for the duration of the task. Attackers exploit this by manipulating delegation chains, role inheritance, or agent-to-agent trust, turning a narrowly scoped instruction into a credential that can chain every permission the principal holds, concurrently, in a single agent turn.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T22 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-Depth Exposed service account credentials bypass the agent entirely: an attacker with the leaked key connects directly to the financial API and operates outside all of the agent's policy controls, audit logging, and rate limits. Depth here means the credential is never a single point of total access: separate, scoped credentials are issued per backend system so that one leaked key does not open every system the agent was authorised to reach, credentials are rotated on a short schedule and invalidated immediately on suspected exposure, and secrets-scanning in CI/CD pipelines and on repository push creates a detective layer that catches leakage before an attacker can act on it. Runtime secrets injection through a secrets management system rather than environment variables or committed config removes the most common leakage path entirely.
- Agent-as-principal Identity The threat is enabled by the same structural problem that afflicts most deployed agents: a single broad-access service account key shared across the agent's full operating scope, so that its exposure grants an attacker the same reach as the agent itself. Per-backend scoped credentials with short TTLs are the identity-layer control: even if one credential is leaked, its scope is bounded to a single system and it expires quickly, making the exfiltration window narrow and the blast radius contained. Secrets management with runtime injection ensures that no credential ever exists in a form that can be committed to version control or logged in a pipeline.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T22, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
-
A Non-Human Identity (NHI) is the service account, machine principal, or formal agent identity under which an agentic system authenticates and acts. When an NHI is provisioned with broad scope, never rotated, and has no named owner, a stolen or leaked credential gives an attacker persistent access for as long as that credential remains valid. NHI lifecycle management treats each agent identity as a first-class governance object: provision narrowly with a declared scope and owner, rotate on a short schedule using platform-native short-lived credentials, audit every authentication and rotation event, re-attest that the identity is still needed, and decommission by deletion when the agent is retired.
why it helps Accidental credential exposure leaves a service-account secret valid and exploitable for as long as it remains unchanged. Aggressive rotation invalidates an accidentally exposed credential before an attacker can act on it; narrow provisioning limits the blast radius of any window where the credential is still valid.
- Tier 2 Secret scan (Secret scanning on agent-generated artefacts — detecting credentials before they escape the trust boundary)
An agent produces code, configuration files, tool-call payloads, and log records continuously and at a rate no human reviewer can match. Any of those artefacts may contain a live API key, service token, or private certificate, placed there accidentally through model context, or deliberately through prompt injection or context poisoning. Secret scanning places an inspection gate at every agent output seam: regex patterns match known token formats, entropy analysis detects arbitrary high-entropy strings, and validator calls confirm which candidates are live credentials. The CI-secret-scanning pattern is mature; the agentic specialisation is seam placement, moving the scanner from the repository gate to the agent egress point, where artefacts can be intercepted before they reach any downstream system.
why it helps T22 covers credential leakage through persistent storage paths: service-account keys committed to repositories, tokens baked into container images, and secrets written to CI logs. Secret scanning at the agent output seam intercepts these before they reach any persistent store, providing direct structural coverage for the credential-leakage scenario that the OWASP MAS Guide identifies for T22.
- Tier 2 Token TTL (Short-lived tokens — bounding the credential exploitation window for agent identities)
An agent identity backed by a long-lived bearer token grants access for as long as that token remains valid. If the token is stolen, logged, or extracted from a running process, the attacker holds working credentials for weeks or months without any further action. Short-lived tokens address this by issuing credentials with a time-to-live measured in minutes or hours, automated and renewed by the platform rather than a human. When a token expires, access ends: the attacker must win the renewal process as well, which requires compromising a harder target than the token itself.
why it helps Accidental credential exposure through commits, container images, or log records leaves a secret readable by anyone who discovers the artefact. Short TTL limits the usable window of the exposed credential to its remaining lifetime, reducing the exploitation value of the exposure even when secret-scanning detection is delayed.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
AML.T0055 Unsecured Credentials view on ATLAS ↗ Adversary discovers credentials stored in plain configuration files, environment variables, or model context where they should not be exposed.
Agentic angle: Agent configuration files (system prompts, tool descriptors, MCP manifests) are a fresh credential exposure surface.
AML.T0083 Credentials from AI Agent Configuration view on ATLAS ↗ Adversary extracts credentials, API keys, or service-account tokens from an agent's configuration files, system prompts, or environment.
AML.T0012 Valid Accounts view on ATLAS ↗ Adversary obtains and abuses legitimate user or service credentials for initial access, persistence, privilege escalation, or defence evasion.
Agentic angle: Agents often run under long-lived service accounts whose blast radius exceeds the original task scope.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §3 RPA Expense Reimbursement Agent — Layer 4 Deployment Infrastructure.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §3 RPA Expense Reimbursement Agent — Layer 4 Deployment Infrastructure