T22 · Helmwart ID · OWASP MAS Guide source
An agent's service-account credentials are accidentally exposed (committed to a repo, left in an env var or image layer), letting an attacker bypass the agent and its controls entirely.
Extends T3: Privilege Compromise · base threat in OWASP v1.1 catalog
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.
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.
Moltbook agent-key exposure (January 2026). Moltbook, a social platform built for AI agents, shipped its Supabase project URL and publishable API key inside the client-side JavaScript bundle. That is the intended design for Supabase: the publishable key is safe in the browser provided Row-Level Security policies constrain what it can reach. Moltbook had no such policies. Wiz Research, which found the key by reading the production bundle, describes the consequence: “without RLS policies, this key grants full database access to anyone who has it. In Moltbook’s implementation, this critical line of defense was missing.” The exposed surface covered “1.5 million API authentication tokens, 35,000 email addresses, and private messages between agents”, roughly 4.75 million records, with write access as well as read. What makes it a T22 case rather than a generic database leak is what sat in the agents table: each row carried that agent’s own api_key, claim_token and verification_code, so the misconfiguration published working credentials for every agent on the platform at once, not for one shared service account. Some of the exposed private messages contained credentials for unrelated services, including plaintext OpenAI API keys that agents had passed to each other. No agent was compromised and no guardrail was defeated; a single missing access-control setting in the deployment made an entire fleet’s identities readable. Wiz disclosed on 31 January 2026 and the platform was fully patched by 01:00 UTC the next day.
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.
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.
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.AKIA…, GCP ya29.…) visible in a job’s stdout. Instrument the pipeline to scan build log output and mask or alert on credential-shaped strings.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.
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:
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.
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.
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).
In most deployments, agents authenticate to one another with long-lived bearer tokens or shared secrets. If any one of those credentials is stolen, the attacker has persistent, platform-wide access until someone manually rotates it. SPIFFE replaces that model: each workload is issued a short-lived, cryptographically verifiable identity document, and every connection requires both sides to present one. No long-lived secrets traverse the network, and a compromised credential is worthless within its TTL.
why it helps Service Account Exposure is a problem about a secret that can be copied. SPIFFE replaces the long-lived service-account credential with a short-lived SVID issued to an attested workload, so there is no static token sitting in a repository, an environment variable or an image layer to find. A credential lifted from a build log expires in minutes and will not attest from the attacker’s host.
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.
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.
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.
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 v2026.09.
© 2026 The MITRE Corporation. ATLAS content is reproduced and distributed with the permission of The MITRE Corporation.
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.
Adapted by Helmwart from the OWASP source(s) above under CC BY-SA 4.0 (changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.
Press play. The voice downloads once, then it’s cached.
On-device · private