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

At a glance

What this is: Delinea’s MCP Server post argues that AI agents should be treated as identities and governed with temporary access, policy enforcement, and audit logging.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to control machine-driven access patterns that can leak secrets, evade audit trails, and outgrow human-era assumptions.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Delinea's analysis of AI agent identity and MCP-based access control

Context

AI agents now sit inside application delivery, access request, and automation workflows, which means they are no longer just tools. They can touch secrets, call APIs, and trigger privileged actions, so the governance question shifts from usage efficiency to identity control. In this article, the primary keyword is AI agent identity, and the central problem is that many enterprises are still treating these actors as software features rather than governed identities.

The gap is structural because traditional PAM and audit patterns were designed around human operators and stable request flows. When an AI agent can request access, receive a token, act, and move on within the same workflow, the organisation needs policy, provenance, and traceability at the identity layer rather than after the fact.

Key questions

Q: How should security teams govern AI agents that access secrets and APIs?

A: Treat each AI agent as a distinct non-human identity with an owner, a policy boundary, and a narrow set of approved actions. Use ephemeral tokens or vault-mediated access instead of exposing reusable secrets, and log every request with identity context so the workflow remains auditable and reviewable.

Q: Why do AI agents create more access risk than ordinary automation?

A: AI agents can choose actions at runtime, call multiple tools, and complete work without the same fixed script that traditional automation follows. That makes their access harder to predict, easier to over-scope, and more likely to cross from assistance into delegated authority unless identity controls are explicit.

Q: What breaks when AI agents are managed with human PAM processes?

A: Human PAM processes assume stable sessions, visible request patterns, and access that persists long enough to be reviewed. AI agents can request, consume, and release access inside a single workflow, which makes traditional approval, certification, and session oversight miss the real control point.

Q: Who is accountable when an AI agent uses privileged access incorrectly?

A: Accountability stays with the organisation that granted the authority, but it must be assigned to a named system owner and policy owner rather than left implicit. Clear ownership, action logging, and control boundaries are what make incident analysis and compliance defensible when agent-driven access goes wrong.

Technical breakdown

Why AI agents behave like identities in enterprise workflows

An AI agent becomes an identity problem when it can access systems, choose actions, and complete tasks that affect production state. In practice, the agent may interact with vaults, admin APIs, or infrastructure tooling through MCP or other orchestration layers. That makes its permissions, token handling, and activity history part of the identity plane, not just the application plane. The governance issue is that the agent can be both the requester and the executor inside one workflow, which blurs conventional separation between application logic and privileged access.

Practical implication: model AI agents as governed identities with explicit entitlements, not as anonymous automation.

Why raw secrets and long-lived credentials create avoidable exposure

The article’s core technical warning is that giving an AI system raw secrets creates a persistence and leakage problem. A secret can be copied into prompts, retained in logs, or exposed through downstream tooling, while a temporary token narrows the exposure window and limits what the agent can reuse. This is the same reason workload identity and ephemeral credentials matter in NHI governance: the credential should prove access without becoming the asset being handled. The control question is less about convenience and more about whether the secret itself ever enters the agent’s operating context.

Practical implication: prefer ephemeral tokens and vault-mediated access paths over exposing reusable credentials to agents.

How identity context and audit logging change trust in MCP workflows

MCP standardises how models call tools, but standardisation does not equal governance. The article highlights the need to attach identity context to each action so teams can see whether a human or an AI triggered it, what policy was applied, and what resource was returned. Without that context, the workflow may be operationally successful while remaining unprovable from a compliance or incident-response standpoint. In identity terms, the issue is provenance: who initiated the action, under what authority, and through which control boundary.

Practical implication: require action-level identity context and auditable policy decisions for every agent request.

NHI Mgmt Group analysis

AI agent identity is now an access governance problem, not just an automation problem. Once an agent can request access, call tools, and return results, the security question shifts to who or what is authorised to act inside that workflow. PAM built for human session control does not automatically map to machine-paced decision loops. The practitioner conclusion is that AI agent governance must be treated as a separate identity discipline, even when the tooling sits inside familiar DevOps or support processes.

Human-paced access review was designed for access that persists long enough to be reviewed. That assumption fails when an AI agent can obtain a token, use it, and complete its task before a reviewer ever sees the entitlement in a meaningful state. The implication is not merely to add more review steps, but to recognise that certification models built around stable, person-owned access do not describe ephemeral machine execution. Teams need to rethink what counts as reviewable access in the first place.

Temporary token mediation is the right design pattern because it reduces credential persistence, but it also exposes a deeper identity blast radius problem. The article points to a world where secrets, API access, and workflow automation are converging. Once the same identity can traverse chat, code, and infrastructure layers, the blast radius is defined by the agent’s reachable tools, not by a single application boundary. The practitioner conclusion is to scope access by task and authority boundary, not by channel.

MCP makes tool connectivity easier, which is exactly why governance has to move earlier in the control stack. Standardised tool access can lower integration friction, but it also normalises privileged machine-to-machine access across many environments. That means organisations need policy enforcement, issuance constraints, and logging expectations before widespread adoption turns exceptions into defaults. The practitioner conclusion is to treat MCP as a control boundary to be governed, not just a connectivity layer to be enabled.

AI-driven workflows will keep expanding until identity teams define the boundary between assistive action and delegated authority. The article shows how quickly AI can move from code assistance to access and operations. Without clear limits, organisations will confuse convenience with delegation and lose sight of who is responsible when actions are taken. The practitioner conclusion is to define authority boundaries for every agent class before those boundaries are bypassed by routine use.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That gap is why the Ultimate Guide to NHIs matters as a forward control baseline for secrets, workload identity, and access governance.

What this signals

AI agent identity will push IAM teams toward task-scoped authority rather than standing entitlements. The practical shift is that access decisions will need to be tied to the specific work item, not the application role. As agentic workflows spread, teams should expect more pressure to prove who or what initiated an action and why the entitlement existed at that moment. For broader control context, align with the OWASP Top 10 for Agentic Applications 2026.

Identity provenance becomes the programme signal that matters most. If an agent can reach a vault, a ticketing system, and an infrastructure API in one path, the key question is whether each hop is recorded with usable identity context. That requirement is already visible in machine identity governance, and it becomes more urgent as human and non-human workflows converge.

Ephemeral access is not just a technical preference, it is a governance boundary. As agentic use cases grow, organisations will need to decide where tokens, vaults, and policy engines sit in the workflow and what evidence they leave behind. Teams that cannot show that evidence will struggle to defend access decisions in audits, investigations, or model-risk reviews.

For practitioners

• Define AI agents as governed identities Assign each agent a distinct identity, owner, and policy boundary before it can access internal systems. Tie that identity to the services, vaults, and APIs it may reach, and prevent shared or opaque credentials from being reused across workflows.
• Replace raw secrets with ephemeral access paths Use temporary tokens and vault-mediated retrieval so the secret itself never becomes part of the agent’s working context. This reduces leakage into prompts, logs, and downstream tooling while preserving task-scoped access.
• Log every agent action with identity context Capture whether a human or AI initiated the action, what policy was evaluated, and what resource was returned. Keep these records available for compliance review, incident investigation, and privilege validation.
• Scope agent permissions to task and time Grant only the minimum tool set and resource scope required for the current task, then revoke access when the workflow completes. Avoid standing privileges that outlive the session or the specific request.

Key takeaways

• AI agents change the identity problem because they can act, request, and complete work inside the same operational path.
• Secrets exposure remains a major risk because the credential itself can leak into prompts, logs, or downstream systems.
• Governance should move to identity context, ephemeral access, and task-scoped policy before agent adoption becomes routine.

Key terms

• AI Agent Identity: An AI agent identity is the governed identity assigned to a software entity that can select actions, use tools, and complete tasks on its own. In practice, it needs ownership, policy boundaries, and audit evidence, just like other non-human identities, because it can directly affect systems and data.
• Ephemeral Access Token: An ephemeral access token is a short-lived credential issued for a specific task or session. It reduces exposure because the agent can prove access without holding a reusable secret, which lowers leakage risk and limits what can be reused if the token is intercepted or logged.
• Identity Context: Identity context is the metadata that explains who or what initiated an action, what policy was applied, and what resource was touched. For AI-driven workflows, it is the difference between activity that can be audited and activity that only appears successful after the fact.
• Tool Scope: Tool scope is the set of actions and systems an agent is allowed to reach. For autonomous or AI-driven workflows, scope must be narrow, task-specific, and revocable, because broad tool access quickly turns convenience into an expanded attack surface.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Delinea: Unlocking AI Agents with Delinea MCP Server. Read the original.