AI agent identity needs policy and audit controls, not raw secrets

At a glance

What this is: This is Delinea’s analysis of why AI agent access to secrets and APIs needs policy enforcement, temporary credentials, and auditable identity context rather than raw secret exposure.

Why it matters: IAM, PAM, and NHI teams need to treat AI agents as active identity subjects because the control gap is no longer authentication alone, but how access is issued, constrained, and reviewed.

Context

AI agent identity is the problem space here: software that can request access, call tools, and trigger workflows needs governance as an identity subject, not just a convenient automation layer. When those agents reach secrets, APIs, and infrastructure, traditional human-focused access models stop describing what is actually happening.

Delinea’s article argues that the gap is between what AI agents can do at runtime and what policy and audit layers can prove after the fact. The practical issue is whether organisations can preserve identity context, limit privilege, and stop raw credentials from becoming the default access pattern.

The article’s starting point is typical for emerging AI operations programmes. Teams are experimenting first and discovering the governance problem later, which is exactly why identity design has to move ahead of scale.

Key questions

Q: What fails when AI agents are given raw secrets instead of mediated access?

A: Raw secrets turn an AI agent into a bearer of privileges rather than a governed requester. That removes policy context, makes revocation harder, and creates leakage risk if the credential is copied into prompts, logs, or model state. The practical failure is not only exposure, but loss of accountability over who or what used the access.

Q: Why do multi-agent systems create audit and accountability gaps in enterprise AI workflows?

A: They distribute work across multiple agents, tools, and model calls, which makes execution easy to trace but harder to govern. Framework logs usually show what ran, not who authorised access or whether policy was enforced. Without external controls, organisations lose clear accountability for sensitive data access, delegated actions, and downstream business decisions.

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: When does an AI agent become an autonomous identity risk?

A: An AI agent becomes an autonomous identity risk when it can independently choose actions, select tools, and execute timing without human approval. At that point, fixed NHI controls are no longer enough because the actor can change scope mid-session. Until then, most agent workflows should be governed as non-autonomous machine identities.

Technical breakdown

Why raw secrets fail for AI agent access

Raw secrets are a poor control plane for AI agents because a secret is a bearer credential, not a policy decision. Once an agent receives a token, API key, or vault secret, the system has no native understanding of intent, task scope, or whether the access should be human-triggered or machine-triggered. That creates a mismatch between access issuance and audit evidence. If the credential is copied into prompts, logs, or model context, it can persist beyond the task that needed it. The result is identity ambiguity: the workflow looks automated, but the authorisation event disappears.

Practical implication: Treat secrets as a last-mile mechanism only, and keep the authorisation decision outside the model context.

MCP access control and identity context

MCP provides a standard way for agents to interact with tools, but the protocol itself does not remove the need for governance. The security question is whether the MCP layer enforces identity context at request time, including who or what initiated the action, what resource was requested, and what policy constrained the response. Without that context, an agent can move from inquiry to execution too easily, and the organisation loses the distinction between a safe read-only request and a privileged operational change. For IAM teams, the important point is that protocol standardisation is not the same as access governance.

Practical implication: Require identity-aware policy checks at the MCP boundary before any sensitive action or response is returned.

Auditability for autonomous and semi-autonomous workflows

Audit logs only help when they capture a meaningful chain of decision, request, and response. For AI agent workflows, that means recording whether a human, an agent, or a scripted process initiated the request, what policy approved it, and which credential form was used. If the organisation only records the end action, it cannot reconstruct accountability after misuse or leakage. This is especially important in mixed workflows where copilots, DevOps automation, and access request assistants may all touch the same entitlement path. The control objective is not just visibility, but traceable identity context across each step of access.

Practical implication: Log actor type, policy decision, and credential form together so audits can reconstruct the full access path.

Threat narrative

Attacker objective: An attacker or misuse path aims to obtain privileged access through the agent workflow without leaving a reliable audit trail or durable policy boundary.

1. Entry begins when an AI agent is allowed to reach secrets, APIs, or infrastructure through an MCP-connected workflow or similar integration.
2. Credential access occurs when raw secrets, tokens, or temporary access artefacts are exposed to the agent instead of being mediated by policy.
3. Escalation follows when the agent can chain tools or actions beyond the original task scope, especially if those steps are not separately authorised.
4. Impact is the loss of traceability, secret leakage, or unintended privileged actions that the organisation cannot confidently explain or prove after the fact.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity is now a policy problem, not just an access problem: once an agent can request secrets, call APIs, and trigger workflows, the control question becomes what policy decides the action, not whether the model can perform it. Human-era PAM assumes a person can be placed inside a reviewable access path. AI agents break that assumption because the requester and executor may be the same runtime object, and the path from request to action can be machine-paced. Practitioners need to treat the agent as an identity subject with enforceable boundaries, not a convenience layer over existing credentials.

Raw secrets create identity blind spots that audit logs cannot repair: when a secret is handed directly to an AI workflow, the organisation has already lost the most important security decision, namely whether the access should have existed at all. This is an OWASP-NHI secret leakage problem amplified by protocolised agent access, because the credential can be copied, cached, or retained outside the original task. The result is not only breach exposure but also governance loss, since the evidence trail no longer proves who had access, when, and under what policy.

Policy and audit controls define the real trust boundary for MCP: the protocol can standardise connectivity, but it cannot by itself determine whether a given agent should see a vault record, invoke an admin API, or receive a short-lived token. That boundary has to be enforced by identity-aware policy and retained in audit context, or the organisation will confuse connectivity with authorisation. The implication for NHI governance is clear: standard interfaces do not eliminate the need for explicit authorisation design.

Identity context must travel with the action, not sit beside it: an access decision that cannot be tied to the actor type, policy rule, and credential form is not auditable enough for AI-driven operations. This is where the AI agent identity model intersects with classical IAM and PAM governance. Teams should assume that any workflow which loses actor context mid-stream will eventually lose accountability as well.

Assumption collapse: access review was designed for stable privileges and reviewable actors. That assumption fails when AI workflows can request, consume, and discard access inside one task or session, leaving little or nothing for a periodic review to inspect. The implication is that governance must move toward issuance-time control and traceable policy enforcement rather than relying on retrospective certification alone.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: Agentic AI Identity Guide

What this signals

Policy boundaries, not model prompts, will decide whether AI operations remain governable: if the access decision sits inside the workflow, organisations will keep confusing capability with authorisation. The stronger pattern is to move decisions to the boundary where the actor, resource, and entitlement are all visible before the task proceeds.

Identity context has to survive the handoff from human request to machine execution: the most fragile moment in AI-driven operations is when an approval becomes an API call and the actor label disappears. That is where auditability, segregation of duties, and change control can fail together, which is why agent governance has to be designed as an identity workflow rather than a tooling feature.

For practitioners

• Map every AI workflow to an identity subject Inventory which copilots, agents, scripts, and assistants can reach secrets, APIs, or infrastructure, and record whether each is human-triggered, agent-triggered, or fully automated.
• Replace raw secret delivery with mediated access Use short-lived tokens or policy-checked access responses instead of exposing reusable secrets directly to the agent or model context.
• Bind logging to the full identity decision chain Capture the initiating actor, policy decision, requested resource, and credential form in the same audit record so investigations can reconstruct the access path.
• Review human-era PAM assumptions against agent workflows Identify where existing approval, checkout, and recertification processes assume a person is holding the privilege long enough to inspect it.
• Constrain MCP-mediated actions by resource class Separate read-only requests from privileged system changes and require policy evaluation before the agent can cross that boundary.

Key takeaways

• AI agents accessing secrets and APIs create an identity governance problem that human-era PAM does not describe well.
• The core weakness is the use of raw secrets and weak audit context, not the existence of automation itself.
• Practitioners need policy enforcement, short-lived access, and full identity context at the point of access issuance.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Identity context: The entitlement, ownership, and purpose information that explains why an action occurred and whether it was expected. For security operations, identity context turns raw alerts into decisions by showing which human or non-human identity acted and what it was allowed to do.
• Exposed Access Token: A secret credential that is unintentionally available to an attacker and can be used to act with the permissions of the owner. In software supply chains, an exposed token may allow package publication, pipeline access, or registry changes without further authentication.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.