AI agents and secrets handling are becoming the new control plane

At a glance

What this is: This is an analysis of how autonomous AI agents become secrets-handling systems once they need credentials to act, and why that shifts risk from secret visibility to action governance.

Why it matters: It matters because IAM, PAM, and NHI programmes must control how agents invoke privileged actions, not just how secrets are stored, rotated, or hidden from prompts.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read Crogl's analysis of AI agents, secrets handling, and autonomous execution

Context

AI agent identity governance starts with a simple question: what identity is the agent actually using when it acts? In this case, the problem is not model quality or workflow speed, but the fact that useful agents need credentials, and credentials turn an agent into a high-value non-human identity with real access paths into security tooling, infrastructure, and data.

The risk increases when those secrets cross the enterprise trust boundary. If tokens, API keys, and service account material can appear in prompts, tool calls, logs, traces, or external LLM systems, then the identity control problem is no longer limited to storage. It becomes a question of who can invoke privileged actions, under what policy, and with what auditability.

That makes the article relevant to IAM, PAM, and NHI governance at the same time. It is not a general AI commentary piece. It is an architectural argument about how agentic systems inherit the same lifecycle, scoping, and accountability problems that already exist for service accounts and other non-human identities, only with more runtime variability.

Key questions

Q: What breaks when AI agents keep standing credentials?

A: The access model breaks because the agent can continue acting after the human has moved on, the workflow has shifted, or the original approval is no longer relevant. Standing credentials turn delegated authority into unattended authority, which is especially risky when agents can retry, chain tools, and move quickly across systems.

Q: Why do AI agents increase secrets risk even when prompts do not expose credentials?

A: Because the risk shifts from visibility to invocation. A model may never see the secret, yet it can still cause a tool to use that secret on its behalf. That means access control, execution policy, and logging are more important than prompt sanitisation alone when governing agentic workflows.

Q: How can security teams tell whether agent permissions are too broad?

A: The clearest signal is whether the agent can still complete its job after permissions are reduced in a sandbox. If the task keeps working after you remove broad access, the original entitlement was inflated. A second signal is the presence of unused permissions that persist across reviews and deployments.

Q: Should organisations treat AI agents like human users in IAM?

A: No. Human IAM assumes a person logs in, works within a session, and can be reviewed later as a stable identity holder. Agents can act at machine speed, across multiple systems, and with changing runtime context, so they need identity governance built around execution and delegation rather than human authentication patterns.

Technical breakdown

How AI agents become secrets-handling systems

Once an agent can query SIEM, EDR, IAM, or runbooks, it needs some form of credentialed access. In practice that means API tokens, OAuth grants, service accounts, or delegated execution layers. The identity risk is not limited to the agent seeing a secret directly. It also includes prompts, tool payloads, logs, memory, and downstream systems that store or replay that material. The moment a model can influence privileged tool use, the secret boundary has moved from disclosure to invocation.

Practical implication: treat agent access as NHI governance, not just LLM safety, and map every secret-bearing path end to end.

MCP changes the exposure model, not the access problem

Model Context Protocol reduces one class of risk by keeping secrets out of the model context and centralising tool access. That means the model may not see credentials, but it can still cause privileged actions to occur through authorised tools. This is a meaningful architectural shift because the control question becomes whether tool execution is sufficiently scoped, gated, and logged. In other words, the secret may stay hidden while the action remains potentially overbroad.

Practical implication: review tool permissions, not just prompt hygiene, when adopting MCP-style architectures.

Why excessive agency is an identity control issue

Excessive agency in agentic systems is the same governance pattern that NHI teams know from over-privileged service accounts, but with runtime decision-making layered on top. If an agent has persistent credentials and broad tool access, least privilege becomes hard to reason about because the system can select actions dynamically. That is an IAM and PAM design problem as much as an AI problem. The concern is not sophistication. It is that authority and execution have been bundled too loosely.

Practical implication: scope agent tokens to the smallest possible task domain and separate intent from execution wherever possible.

Threat narrative

Attacker objective: The objective is to turn a trusted AI workflow into a pathway for secret exposure, privileged invocation, and broader internal system access.

1. Entry occurs when an attacker or malicious input reaches an agent workflow that already has access to internal tools, secrets, or delegated credentials.
2. Escalation occurs when the agent is induced to reveal data, call sensitive tools, or reuse broad permissions beyond the original task intent.
3. Impact occurs when the agent triggers unintended privileged actions, exposes internal data, or expands the attacker’s reach across connected systems.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Autonomous agents turn secrets governance into action governance. The important shift is not that agents may see credentials, but that they can be asked to use them at runtime. That means identity programmes must govern invocation paths, not only secret storage. The practitioner conclusion is that agent access reviews need to cover tool reach, execution scope, and delegated authority together.

Separation of intent from execution is now an identity control boundary. The article’s strongest point is architectural: the LLM decides what should happen, while a controlled layer decides how it happens. That pattern reduces exposure, but it also makes the execution layer the real security perimeter. The practitioner conclusion is that agent governance must move from prompt controls to policy-enforced action control.

Excessive agency is the same failure mode as standing privilege, with more volatility. Persistent credentials and broad tool access create the familiar NHI problem of access that outlives purpose. Autonomous decision-making makes that worse because the agent can select actions at runtime rather than following a fixed script. The practitioner conclusion is that least privilege must be defined at the action boundary, not just at provisioning time.

LLM context boundaries do not eliminate the NHI trust problem. Keeping secrets out of prompts is necessary, but it does not answer who can trigger credentialed actions, who can chain tools, or how much authority the agent inherits. That is the same underlying governance assumption that breaks in many NHI programmes: if access is hidden, it is presumed safe. The practitioner conclusion is to govern usage rights, not only secret visibility.

Runtime control for AI agents is becoming a named governance gap. Agent action authority: this is the point at which a system can no longer be judged only by what it stores, because its real risk lies in what it can cause to happen. That distinction matters for IAM, PAM, and NHI teams because the accountable unit is the action path, not the model prompt. The practitioner conclusion is that agent governance should be audited as a control plane, not as a chatbot feature.

From our research:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be critical than code-based leaks.
• That is why teams should also review the Guide to the Secret Sprawl Challenge when designing detection and revocation workflows.

What this signals

Agentic access governance is now a control-plane issue, not a model-risk side topic. The more an AI system can act across SIEM, IAM, and EDR, the more its credential paths behave like privileged infrastructure. With 81.5% year-over-year growth in AI-related credential leaks, per The State of Secrets Sprawl 2026, the programme failure is usually not visibility alone. It is the absence of a control boundary between intent and execution.

Separation of execution from prompt context is becoming a named design requirement. Keeping secrets out of the model context helps, but it does not solve delegated authority, action scoping, or audit attribution. Teams that already manage service account sprawl should recognise the pattern immediately because agentic systems reintroduce the same lifecycle problem through a more dynamic interface.

The next governance step is to align agent access with the same discipline used for privileged non-human identities, then extend it to autonomous runtime behaviour where needed. That means tighter approval boundaries, narrower tool scope, and explicit review of who or what can trigger a secret-bearing action.

For practitioners

• Map agent-to-tool authority paths Inventory every tool, API, and workflow an agent can trigger, then document which credential or delegated identity executes each action. Focus on the full action path, not just the prompt surface or model provider boundary.
• Separate model intent from credential use Design architectures so the LLM can request an action without directly receiving secrets, tokens, or long-lived credentials. Keep credential material in a controlled execution layer with policy checks and logging.
• Scope agent privileges to task boundaries Replace broad, persistent access with task-scoped permissions that match the smallest realistic work unit. Review whether current tokens can rotate, expire, or be revoked without breaking essential automation.
• Audit prompts, logs, and traces for secret leakage Treat observability systems as part of the secret surface. Search for tokens, keys, and OAuth material in prompts, tool payloads, logs, traces, and memory stores, then remove or redact where needed.

Key takeaways

• AI agents become a secrets-handling problem as soon as they can act on internal systems, because their value depends on credentialed access.
• The critical control gap is no longer secret visibility alone, but who can trigger privileged actions and how that invocation is governed.
• IAM, PAM, and NHI teams should separate model intent from execution authority so agent autonomy does not become standing privilege by another name.

Key terms

• Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
• Secret Isolation: A design pattern that keeps secrets out of prompts, model memory, and tool payloads while preserving controlled execution. It reduces exposure, but only works when the execution layer independently enforces permissions and logs every action.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• Execution Layer: The execution layer is the operational point where identity policy becomes system change. It is where approvals, provisioning, revocation, and session controls either complete successfully or fail in ways that create drift. For practitioners, this is where governance is proven, not merely documented.

What's in the full article

Crogl's full blog covers the operational detail this post intentionally leaves for the source:

• The article’s architecture pattern for keeping secrets out of prompts while still allowing controlled tool execution.
• Crogl's explanation of how role-based controls scope agent actions inside a controlled execution layer.
• The distinction between system-required exposure and user-driven disclosure, which matters for governance decisions.
• The audit-trail and attribution model used when every agent action must remain traceable.

👉 Crogl's full post covers the MCP architecture, execution boundaries, and secret-isolation pattern in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.