Notifications
Clear all
Topic starter
25/06/2026 12:48 am
TL;DR: AI agents are beginning to access secrets, APIs, and infrastructure directly, which expands the identity attack surface and exposes audit gaps when traditional PAM is built for human users, according to Delinea. The governance problem is not AI capability itself but the assumption that access can still be handed out, logged, and reviewed like a normal human workflow.
NHIMG editorial — based on content published by Delinea: Unlocking AI Agents with Delinea MCP Server
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Define AI agents as governed identities Assign each agent a distinct identity, owner, and policy boundary before it can access internal systems.
- 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.
- 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.
What's in the full article
Delinea's full blog post covers the operational detail this post intentionally leaves for the source:
- Open-source MCP Server deployment details for connecting AI agents to the Delinea Platform
- Examples of how temporary access tokens replace raw secrets in agent workflows
- Identity-aware logging patterns for human-triggered versus AI-triggered actions
- Workflow examples for access requests, DevOps scripts, and assistant-driven operations
👉 Read Delinea's analysis of AI agent identity and MCP-based access control →
AI agent identity and MCP access: are your controls keeping up?
Explore further
25/06/2026 9:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent identity needs policy and audit controls, not raw secrets
