Six independent research teams disclosed exploits against AI coding agents between March and June 2026. Every single one highlighted the same AI agent credential security gap: the credentials the agent held at runtime.
Not the model. Not the prompt. The credentials.
BeyondTrust proved a crafted GitHub branch name could steal Codex’s OAuth token in cleartext. Unit 42 found that default Vertex AI service accounts had unrestricted access to every Cloud Storage bucket in the project. Cursor running Claude Opus 4.6 found a root-level Railway API token in an unrelated file and deleted PocketOS’s production database and all backups in nine seconds. IAM audit logs recorded all of it as service account actions. No human session. No anomaly flag. No alert.
This is not a model safety problem. It is a structural IAM problem, and the tools your team built to govern human identity are the wrong tools for the job.
The Pattern Nobody Is Talking About
Six Exploits, One Vector: Why Attackers Target Agent Credentials
The attacks read differently in individual incident reports. String them together and the pattern is unmistakable.
flowchart TD
A[Agent Deployed to Kubernetes] --> B{Credential Discovery}
B --> |OAuth flow| C[Codex: OAuth token via crafted branch name]
B --> |Metadata service| D[Vertex AI: P4SA token via metadata endpoint]
B --> |Static file in repo| E[Cursor/PocketOS: Railway API token in unrelated file]
C --> F[Authenticate to Production System]
D --> F
E --> F
F --> G{Action Taken}
G --> |Codex| H[Token exfiltrated: Critical P1]
G --> |Vertex AI| I[Unrestricted read across all GCS buckets]
G --> |PocketOS| J[Production DB + all backups deleted in 9 seconds]
H --> K[IAM Audit Log: service-account@project.iam<br/>No human session anchor]
I --> K
J --> K
K --> L[Incident detected after damage, or not at all]The common attack structure across the 2026 AI coding agent exploits. The credential discovery mechanism varies. The outcome does not.
The mechanism is consistent: the agent holds a credential, the credential authenticates to a production system, and IAM records the action under a service account identifier with no link to the AI agent that performed it or the human who triggered the session.
Adversa’s research on Claude Code adds another dimension: Claude Code silently ignored its own deny rules once a command exceeded 50 subcommands, enabling unauthorized credential use even when explicit safety controls were in place. The exploit path did not require breaking the model. It required finding the point where the agent’s rule engine stopped checking.
The inference for attackers is straightforward: manipulating a model is probabilistic and unreliable. Stealing a credential with valid API access is deterministic.
24,000 MCP Secrets and Counting
GitGuardian’s 2026 State of Secrets Sprawl report documents the supply-side problem. In 2025, 28.6 million new secrets were exposed in public GitHub commits - a 34% year-over-year increase, the largest jump in the report’s history. Of those, 1.2 million were AI-service secrets, growing at 81% year-over-year.
The MCP figure is the most operationally significant: 24,008 unique secrets discovered in MCP configuration files on public GitHub. Of those, 2,117 (8.8%) were confirmed valid credentials. Google API keys made up roughly 20%, PostgreSQL connection strings 14%.
The leak mechanism is identical across incidents: a developer copies an MCP server configuration from a tutorial, drops a real API key into the example placeholder, gets the tool working, and commits the file. MCP tooling is new enough that most security teams have not added these file patterns to their scanner allowlists or pre-commit hooks.
Commits co-authored by Claude Code leaked secrets at roughly double the baseline rate across public GitHub. The same pattern holds for any tool that writes configuration files as a side effect of doing useful work.
Why Your IAM Stack Cannot See Your Agents
Why Does Traditional IAM Break for Autonomous AI Agents?
Traditional IAM was designed around three assumptions that do not hold for autonomous agents.
graph LR
subgraph Human["Human IAM (Designed For)"]
H1["SSO Login"] --> H2["Session Token"]
H2 --> H3["90-Day Rotation"]
H3 --> H4["Quarterly Access Review"]
H4 --> H5["Human Audit Trail"]
end
subgraph Agent["Agent Reality (What Breaks)"]
A1["No Login Event"] --> A2["Static API Key"]
A2 --> A3["No Rotation Schedule"]
A3 --> A4["No Access Review"]
A4 --> A5["serviceaccount in Logs"]
end
subgraph Fix["Workload Identity (The Fix)"]
F1["SPIRE Attestation"] --> F2["SVID: 1hr Validity"]
F2 --> F3["Auto-Rotation on Node"]
F3 --> F4["OPA Policy Enforcement"]
F4 --> F5["Per-Agent Audit Trail"]
endTraditional IAM assumptions versus agent reality versus the workload identity model that closes the gap.
Session-anchored identity. Every human IAM system assumes a session anchor: an SSO login, an MFA challenge, a session cookie that ties actions to a human decision point. Agents authenticate without human sessions. When a Vertex AI agent calls Cloud Storage, IAM sees an API call from a service account. There is no human session to anchor responsibility, no login event to trigger anomaly detection, and no expiring session to limit blast radius.
Static credential lifecycle. Organizations manage credentials on human timescales: 90-day rotation policies, quarterly access reviews, annual permission audits. Agents operate in seconds. The PocketOS agent discovered and used a destructive token in nine seconds. A quarterly rotation policy provides zero protection against an agent that can traverse a filesystem and make API calls faster than any human can respond.
Permission-vs-pattern blindness. IAM validates authorization: does this identity have permission to perform this action? It does not validate behavioral intent. As ARMO’s research articulates: if an AI agent’s service account has roles/bigquery.dataViewer on a dataset, the token works identically for a 500-row analytics query and a 10-million-row exfiltration. The permission check passes. The behavioral anomaly is invisible to the authorization layer.
Stacklok’s analysis identifies a fourth structural failure in multi-agent systems: the bearer token model grants permissions across all tool calls regardless of task scope. A single token issued for one workflow authorizes the agent across every API it can reach. Multi-agent architectures compound this through token sharing, static sub-agent credentials, or unauthenticated inter-agent communication - three patterns that each create distinct attack surfaces.
The Enterprise Reality: 88% Incident Rate, 21% Visibility
A VentureBeat survey from June 2026 puts numbers to the governance failure: 88% of enterprises reported AI agent security incidents in the past year. Only 21% have runtime visibility into agent actions.
Strata’s research correlates static credentials directly with incidents: 67% of organizations relying on static API keys and long-lived tokens for agent authentication showed a 20-percentage-point increase in AI-related incidents compared to organizations using short-lived credential patterns. HiddenLayer’s 2026 AI Threat Landscape Report finds 1 in 8 AI security breaches now linked to agentic systems. 31% of organizations in the survey cannot determine whether they have experienced an AI breach.
The visibility gap has a structural cause. SIEM and CSPM tools were designed for human-operated workloads with predictable access patterns: a user logs in, accesses specific resources, logs out. AI agents generate high-frequency, multi-system, tool-driven access patterns that do not match any established anomaly baseline. The agent running a legitimate code review produces the same IAM signal pattern as an agent that has been instructed to exfiltrate the repository.
The Four-Layer Kubernetes Remediation Stack
No single control closes the IAM gap for agents. The credential targeting pattern succeeds precisely because it exploits the spaces between controls: configuration management misses runtime credentials, admission control misses behavioral anomalies, and static IAM rules miss the gap between permission and intent.
The remediation stack addresses each gap in sequence.
graph TB
subgraph L4["Layer 4: Runtime Monitoring"]
R1["Falco eBPF Rules"]
R2["Agent Config Dir Access"]
R3["Credential File Reads"]
R4["Safety Control Bypass Detection"]
R1 --- R2 --- R3 --- R4
end
subgraph L3["Layer 3: Admission Control"]
P1["Kyverno / OPA Gatekeeper"]
P2["No cluster-admin ServiceAccounts"]
P3["Projected Token Enforcement"]
P4["Resource-Level IAM Scope"]
P1 --- P2 --- P3 --- P4
end
subgraph L2["Layer 2: Short-Lived Credentials"]
C1["Projected SA Tokens"]
C2["GKE Workload Identity Federation"]
C3["AWS STS Session Policies"]
C4["Graduated Trust Model"]
C1 --- C2 --- C3 --- C4
end
subgraph L1["Layer 1: Workload Identity"]
W1["SPIRE Server + Agent"]
W2["X.509 SVID per Workload"]
W3["mTLS Between Agents"]
W4["Vault SPIFFE Auth"]
W1 --- W2 --- W3 --- W4
end
L1 --> L2 --> L3 --> L4The four-layer stack addresses distinct failure modes: identity provenance, credential lifetime, deployment policy, and behavioral anomalies.
Layer 1: Workload Identity with SPIFFE/SPIRE
SPIFFE (Secure Production Identity Framework for Everyone) eliminates the static credential problem at the root. Each agent workload receives a SPIFFE Verifiable Identity Document (SVID) based on its runtime attestation, not on a secret stored in a configuration file.
SVIDs are short-lived (1-hour default validity), automatically renewed by the SPIRE agent running on each Kubernetes node, and cryptographically bound to the workload’s deployment context. Identity is based on where the workload is running and how it was deployed, not on a secret that could be copied to another file.
This directly prevents the PocketOS failure mode. An agent without proper SPIRE provisioning cannot obtain valid credentials regardless of what it finds in the filesystem. Finding a token in an unrelated file provides no useful authentication material because the system expects attestation-based identity, not bearer tokens.
The production-ready reference architecture as of mid-2026, documented by HashiCorp:
- SPIRE deployed as the enterprise workload identity authority
- Every agent container receives an SVID on startup via SPIRE’s Kubernetes workload attestor
- mTLS between agents enforces zero-trust authentication at the network layer
- Vault Enterprise integrates as a SPIFFE-aware secrets engine, issuing both X.509 SVIDs and JWT SVIDs
- OpenFGA or SpiceDB provides relationship-based authorization layered on top of SPIFFE identity
Stacklok’s vMCP gateway extends this to the tool-call level: every MCP tool call generates an OpenTelemetry trace that includes the resolved agent SPIFFE ID, the MCP server invoked, the tool called, and the authorization result. This creates an agent-specific audit trail that existing SIEM infrastructure can consume without any changes to the SIEM configuration.
Layer 2: Short-Lived Credentials and Graduated Trust
Kubernetes projected service account tokens (available since v1.22) replace the legacy non-expiring tokens that power most current agent deployments. The security properties are fundamental changes, not incremental improvements:
- Bounded lifetime: Tokens expire automatically and rotate transparently via the kubelet
- Audience scoping: Tokens are bound to a specific audience, limiting where they can authenticate
- Auto-invalidation: Tokens are invalidated when the pod is deleted
The configuration that implements this for an agent job:
apiVersion: batch/v1
kind: Job
metadata:
name: agent-investigation-{{ investigation_id }}
namespace: ai-agents
labels:
trust-phase: "shadow"
spec:
activeDeadlineSeconds: 900
ttlSecondsAfterFinished: 3600
template:
spec:
serviceAccountName: agent-phase-shadow
automountServiceAccountToken: false
containers:
- name: agent
image: registry.example.com/ai-agent:v1.2.0
resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "2"
memory: "4Gi"
volumeMounts:
- name: sa-token
mountPath: /var/run/secrets/tokens
readOnly: true
volumes:
- name: sa-token
projected:
sources:
- serviceAccountToken:
path: agent-token
expirationSeconds: 3600
audience: "https://vault.example.com"
restartPolicy: NeverautomountServiceAccountToken: false prevents the default legacy token mount. The projected volume provides a 1-hour token scoped to Vault’s audience, not the cluster-wide Kubernetes API. When the job completes, the pod is deleted and the token is invalidated.
For AWS, STS AssumeRole with session policies enables per-call credential scoping through MCP context keys:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyDestructiveViaMCP",
"Effect": "Deny",
"Action": [
"s3:DeleteObject",
"s3:DeleteBucket",
"dynamodb:DeleteTable",
"rds:DeleteDBInstance"
],
"Resource": "*",
"Condition": {
"Bool": {
"aws:ViaAWSMCPService": "true"
}
}
}
]
}This policy denies destructive operations whenever the caller context includes aws:ViaAWSMCPService: true - blocking the class of damage PocketOS experienced at the authorization layer rather than relying on the agent not discovering the token.
The InfoQ graduated trust model ties credential scope to agent maturity:
flowchart LR
S["Shadow\nRead-only RBAC\nNo secrets access\nGate: 95% diagnostic accuracy"] --> R["Read-Only Assist\nData source access\nScoped Vault paths\nGate: 90% operator agreement"]
R --> L["Limited Remediation\nScoped write access\nSpecific Vault paths\nGate: 99% success rate"]
L --> A["Autonomous L1\nAll approved actions\nFull Vault policy\nDemotion if accuracy drops"]Credential scope expands only when the agent demonstrates the accuracy required for that phase. Each phase runs in an isolated Kubernetes Job with its own ServiceAccount.
The corresponding RBAC for the shadow phase:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: agent-phase-shadow
namespace: ai-agents
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "events"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: agent-phase-shadow-binding
namespace: ai-agents
subjects:
- kind: ServiceAccount
name: agent-phase-shadow
namespace: ai-agents
roleRef:
kind: Role
name: agent-phase-shadow
apiGroup: rbac.authorization.k8s.ioA shadow-phase agent can observe pods, logs, and events. It cannot write, delete, or access secrets. Promotion to the next phase requires meeting the defined accuracy threshold through the observability layer.
Layer 3: Policy Enforcement at Admission
Admission control prevents overprivileged agents from deploying in the first place. Kyverno 1.17 (February 2026) promotes the CEL policy engine to v1, aligning with upstream Kubernetes ValidatingAdmissionPolicies. OPA Gatekeeper v3.22 defaults the sync-vap-enforcement-scope flag to true, unifying the ValidatingAdmissionPolicy enforcement surface with ConstraintTemplates.
Policy targets for agent workloads:
- Validate that agent ServiceAccounts have proper RBAC bindings and never use
cluster-admin - Enforce projected service account token volumes instead of legacy token mounts
- Restrict agent pods to specific namespaces with NetworkPolicy isolation
- Deny
hostPathmounts and privileged container configurations - Generate RBAC RoleBindings automatically for new agent namespaces
The cloud IAM scoping is equally important. The Unit 42 Vertex AI research showed the default P4SA service identity carries project-level grants. The difference between vulnerable and safe is a single command:
# WRONG: Project-level grant (the Vertex AI default Unit 42 exploited)
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:agent-sa@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/aiplatform.user"
# RIGHT: Resource-level grant (specific endpoint only)
gcloud ai endpoints add-iam-policy-binding ENDPOINT_ID \
--region=us-central1 \
--member="serviceAccount:agent-sa@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/aiplatform.user"The project-level grant gives the agent implicit access to every resource in the project. The endpoint-level grant scopes the token to one specific Vertex AI endpoint. When the agent’s credentials are compromised, the blast radius is the endpoint, not the project.
CSA’s MAESTRO framework recommends treating AI agent service account configuration as a security audit criterion: if your organization applies for STAR certification, IAM scope for agent service accounts should be a directly assessable control, not a configuration assumption.
Layer 4: Runtime Monitoring with Falco
Admission control stops misconfiguration. Runtime monitoring catches what policy cannot: an agent using legitimate permissions to do something it should not.
Sysdig’s Falco runtime security for AI coding agents (released March 2026) provides eBPF detection for the specific behaviors that precede credential misuse:
- Config directory access: Flags any process outside the agent’s own process family that performs file I/O on agent configuration folders (
~/.claude/,~/.gemini/,~/.codex/) - Safety control bypass: Detects known unsafe flags at agent invocation that disable permission prompts
- Sensitive file access: Monitors unauthorized file reads by agent processes, including credential file access
- Installation detection: Identifies when package managers spawn agent installation processes outside the provisioned deployment path
These rules map to MITRE ATLAS techniques: AML.T0051.001 for indirect prompt injection and AML.T0083 for credential access.
Microsoft’s Agent Governance Toolkit (open-sourced April 2, 2026) provides complementary deterministic policy enforcement deployable as an AKS sidecar. Its Agent OS package intercepts every agent action before execution at sub-millisecond latency (p99 below 0.1ms), addressing all 10 OWASP agentic AI risks through YAML, OPA Rego, and Cedar policy rules.
ARMO’s research identifies the monitoring gap that neither Falco rules nor admission policy can close alone: eBPF behavioral baselines. The baseline distinguishes a 500-row analytics query from a 10-million-row exfiltration based on data volume, API call sequence, and process lineage. This operates inside the pod to contextualize allowed API calls in ways that a firewall rule or RBAC policy cannot.
What to Do Monday Morning
The four-layer stack is the complete remediation. The Monday morning version addresses the three highest-risk patterns from 2026’s exploit record.
Audit all agent-held credentials. List every ServiceAccount in your agent namespaces:
kubectl get serviceaccounts -n ai-agents -o wide
kubectl get rolebindings,clusterrolebindings -o wide -n ai-agents | grep agentFor each ServiceAccount, verify whether it uses legacy non-expiring token mounts or projected tokens. Any pod with automountServiceAccountToken: true (or unset, which defaults to true) and no projected token override is using the vulnerable pattern.
Replace static tokens with projected service account tokens. Set automountServiceAccountToken: false on every agent pod spec and mount a projected token with expirationSeconds: 3600 scoped to the specific audience the agent needs. This single change eliminates the bearer token problem at the Kubernetes layer without requiring SPIFFE/SPIRE to be in place first.
Scope cloud IAM to specific resources. Check your current IAM bindings for roles/aiplatform.user, roles/storage.objectViewer, or any similar role applied at the project level for agent service accounts. Move every binding to the specific endpoint, bucket, or dataset the agent actually uses.
Deploy Falco rules for agent config directory and credential file access. Deploy in monitor mode first to establish baselines before switching to enforce mode.
These four changes address the specific failure modes in the 2026 exploit record. They do not require a full migration to SPIFFE/SPIRE, though that remains the correct long-term architecture. They reduce your immediate risk while the workload identity infrastructure is being built.
Frequently Asked Questions
Why do AI agent exploits target credentials instead of the model itself?
Credentials grant direct access to production systems while model manipulation is indirect and unreliable. An agent with a valid API token can execute destructive operations immediately, as the PocketOS incident showed in nine seconds. Prompt injection is the initial vector in some attacks, but the payload is always credential access. Every major 2026 exploit (Codex OAuth theft, Vertex AI P4SA, Cursor database wipe) targeted the credentials the agent held, not the model weights.
What is a SPIFFE ID and how does it replace API keys for AI agents?
A SPIFFE ID is a cryptographic workload identity formatted as a URI like spiffe://trust-domain/workload-path that is automatically issued to an agent based on its runtime attestation, not a secret stored in a config file. Unlike an API key, it cannot be copied to another file or machine. SVIDs are short-lived (1 hour by default), automatically rotated, and tied to the specific workload deployment. Even if an agent’s filesystem is compromised, the attacker gets a credential that expires in under an hour and cannot authenticate from a different context.
How do I audit what credentials my AI agents currently have access to?
Start with your Kubernetes cluster: list all ServiceAccounts in agent namespaces (kubectl get sa -n ai-agents), check their RBAC bindings (kubectl get rolebindings,clusterrolebindings -o wide | grep agent), and verify whether they use projected tokens or legacy non-expiring tokens. For cloud credentials, check IAM bindings at the project level versus the resource level. The Unit 42 Vertex AI research showed that default P4SA credentials had project-wide storage access. On AWS, use CloudTrail to search for invokedBy: "aws-mcp.amazonaws.com" to identify agent-initiated actions.
Can I use my existing SIEM to monitor AI agent credential access?
Not effectively with default configurations. SIEM and CSPM tools were designed for human-operated workloads with predictable access patterns. AI agents generate high-frequency, multi-system, tool-driven access patterns that do not match established anomaly baselines. Falco’s AI coding agent detection rules and Microsoft’s Agent Governance Toolkit add the agent-specific context layer that feeds into your existing SIEM. These tools do not replace your SIEM; they provide the translation layer that makes agent behavior legible to it.
What is the fastest way to reduce AI agent credential risk in my Kubernetes cluster today?
Three changes you can make immediately: (1) Replace legacy service account tokens by setting automountServiceAccountToken: false and mounting a projected volume with expirationSeconds: 3600 and a specific audience. (2) Scope cloud IAM bindings to specific resources instead of project-level grants - bind roles/aiplatform.user to a specific endpoint, not the project. (3) Deploy Falco with agent-specific detection rules to monitor config directory access and credential file reads by agent processes. These three changes address the three most exploited patterns in 2026 agent breaches.