Agentic AI security needs identity controls, not just automation

At a glance

What this is: This is a Keyfactor analysis of why agentic AI changes the identity and trust model for enterprise security, with PKI, mTLS, and revocable access presented as the core control themes.

Why it matters: It matters because AI agents, workload identities, and human governance are converging, and security teams need a way to control autonomous access without relying on static secrets or human-paced review cycles.

By the numbers:

• Over half of respondents said they’ve already deployed custom AI agents (53%).
• According to Cisco, identity-based attacks were the most common attack vector in 2024, accounting for 60% of all incident response cases.
• Gartner predicts that by 2029, the use of AI agents could generate up to 30% reduction in operational costs for common customer service issues.

👉 Read Keyfactor's analysis of securing agentic AI with digital trust

Context

Agentic AI changes the identity problem because the system does not just respond to requests, it can choose actions, call tools, and move across services in real time. That means existing IAM assumptions about who or what is acting, when access is used, and how long privileges persist become much harder to trust once the actor is autonomous.

The security gap is not simply more automation. It is the emergence of a runtime identity that can cross APIs, cloud services, and enterprise data ecosystems without the human pacing that most governance models still assume. For IAM, NHI, and PAM teams, the question becomes whether trust is being enforced at the identity layer or inferred from software behaviour after the fact.

Key questions

Q: How should security teams govern identity for agentic AI systems?

A: Security teams should govern agentic AI as a runtime identity problem. Each agent needs a distinct identity, explicit policy scope, auditable access, and a revocation path that works immediately when behaviour changes. Static credentials and human-paced approval cycles are too slow for software that can independently initiate actions across tools and services.

Q: Why do agentic AI systems challenge existing IAM and PAM controls?

A: They challenge existing controls because IAM and PAM often assume access is stable, request-driven, and reviewable over time. Agentic systems can change actions mid-session, so controls based on periodic review, static roles, or broad service accounts do not reliably constrain what the agent can do.

Q: What do organisations get wrong about securing AI agents with secrets?

A: They often treat shared secrets and fixed tokens as acceptable trust mechanisms for agents that behave dynamically. That approach creates durable credentials for a system that may need short-lived, tightly scoped, and revocable trust. The better model is cryptographic identity with connection-level verification and fast revocation.

Q: Who is accountable when an AI agent misuses access or causes damage?

A: Accountability should sit with the business owner of the agent, not with the technology stack alone. Governance teams need a named owner, an approved use case, documented access boundaries, and a way to prove when access was removed. Without that, responsibility is diffused and incidents become harder to investigate.

Technical breakdown

Why agentic AI turns identity into a runtime control problem

Agentic AI differs from conventional automation because it can independently choose actions, invoke tools, and sequence tasks as conditions change. That makes identity verification, authorisation, and auditability runtime properties rather than one-time setup tasks. In practice, this shifts the control plane from static access provisioning to continuous trust decisions across every tool call and data exchange. If the identity layer only authenticates the initial session but cannot bound what the agent may do next, the control model is incomplete.

Practical implication: treat agent sessions as continuously governed runtime identities, not as fixed workloads with one-time access approval.

MCP, OAuth, and why static secrets are a weak trust model

Model Context Protocol can connect agents to tools and data sources, but the trust model matters more than the transport. Keyfactor notes that many current MCP implementations rely on OAuth with fixed keys or shared secrets, which creates durable credentials for systems that may operate only briefly or change behaviour mid-session. That is a poor fit for autonomous access because static secrets are easy to reuse and hard to scope to specific actions. Certificate-based authentication and mTLS are attractive here because they bind trust to cryptographic identity instead of reusable shared material.

Practical implication: replace long-lived shared secrets with cryptographic identities that can be validated per connection and revoked quickly.

Auditability and revocation are the real governance test

The article’s strongest governance point is not that agentic AI is powerful, but that unmanaged autonomy defeats weak oversight. Auditability matters because security teams need to see what the agent accessed and whether its behaviour stayed inside policy. Revocation matters because an agent that drifts from expected behaviour must lose access immediately, not at the next review cycle. In NHI terms, this is the difference between granting a credential and controlling its lifecycle across the entire operational window.

Practical implication: make revocation and anomaly visibility mandatory controls for every agent identity before production rollout.

Threat narrative

Attacker objective: The attacker’s objective is to leverage compromised agent trust to reach data, systems, or actions that the original access model did not intend to permit.

1. Entry occurs when an attacker abuses weak agent trust boundaries, especially where shared secrets or poorly protected API access are used to connect agentic systems to tools and data sources.
2. Escalation follows when the agent can initiate actions across APIs and cloud services, allowing compromised identity or manipulated behaviour to expand access beyond the intended task boundary.
3. Impact is realised through data exposure, unauthorised actions, or operational disruption because the autonomous system can move faster and with less transparency than a human-operated workflow.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Agentic AI creates an identity governance problem, not just an application-security problem. Once a system can choose actions at runtime, identity is no longer a login event or a provisioning record. It becomes the mechanism through which every tool call, data access, and execution step is authorised or denied. The implication is that IAM, NHI, and PAM teams have to govern behaviour at runtime, not simply certify access after the fact.

Static trust assumptions do not survive autonomous execution. Access review processes were designed for access that persists long enough to be observed, questioned, and recertified. That assumption fails when an agent can acquire, use, and discard privileges within a single operational session. The implication is that review cadences alone cannot describe or control agent behaviour, because the artefact of access may already be gone by the time governance catches up.

MCP safety depends on whether identity is cryptographically bound, not merely connected. The article points to a familiar failure mode: reusable secrets and weak authentication patterns being carried into a new execution model. That is not a tooling gap, it is a governance gap around how trust is delegated to software that can act independently. The implication is that enterprise architecture should treat cryptographic identity as the baseline for agent access, especially where tool access and data access converge.

Revocable trust is the named control concept this market is converging on. Agentic systems cannot be governed on the assumption that approval at launch equals safety at runtime. Trust must be continuously enforceable, visible, and withdrawable when behaviour changes. The implication is that the security market will increasingly reward controls that can prove current authorisation state rather than simply record that it once existed.

Identity-based attack thinking now applies directly to autonomous systems. If identity-based attacks remain the dominant enterprise intrusion path, then agentic AI simply extends that risk into systems that move faster and with less human oversight. The implication is that autonomous AI should be folded into existing identity threat models, not separated into a distant AI-only program.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap is why teams should also study OWASP Agentic AI Top 10 before expanding autonomous access.

What this signals

Revocable trust is becoming the practical dividing line for agentic AI programmes. With only 44% of organisations reporting any policy coverage for AI agents, many enterprise rollouts still rely on implicit trust rather than explicit lifecycle control. Teams should expect governance pressure to move from pilot approval to runtime enforcement, especially where agent access touches sensitive data or external APIs.

Agent identity should now be planned alongside NHI and human IAM, not after deployment. The more autonomous the system, the less useful it is to treat it as a special-case workload. Programmes that already use cryptographic identity patterns for machine access should extend those controls to agent access and align them with NIST AI Risk Management Framework principles for governance and monitoring.

With 52% of companies able to track and audit the data their AI agents access, visibility is still too thin for reliable incident reconstruction. That means security leaders should assume the first production failure will be an observability failure, then build logging, policy evidence, and access removal paths accordingly.

For practitioners

• Define agent identities as governed runtime subjects Assign each agent a distinct identity, owner, and policy boundary so access can be tied to a specific business function rather than a shared system role.
• Replace shared secrets with cryptographic authentication Use certificate-based authentication and mutual TLS for agent-to-service connections where possible, and eliminate fixed keys from long-lived integrations.
• Make revocation a first-class control Build a kill switch and lifecycle revocation path that can remove an agent’s access the moment behaviour drifts outside policy or mission scope.
• Instrument agent access for audit and anomaly review Log tool calls, data access, and policy decisions in a form SIEM and governance teams can review, then test whether the logs are sufficient for incident reconstruction.
• Stress-test autonomous workflows before production Run abuse-case testing against agent access paths, especially where APIs, cloud services, and enterprise data are chained together under one identity.

Key takeaways

• Agentic AI changes the identity problem from access provisioning to runtime governance.
• Many organisations are deploying AI agents faster than they are putting policy and audit controls around them.
• Cryptographic identity, auditability, and immediate revocation are the controls that separate managed autonomy from unmanaged risk.

Key terms

• Agentic AI: Artificial intelligence that can independently choose actions, call tools, and execute tasks without waiting for a human to approve each step. In identity terms, it behaves like a runtime subject with its own access lifecycle, which changes how authorisation, audit, and revocation must work.
• Digital Trust: The combination of identity verification, authentication, policy enforcement, and monitoring that establishes whether a system should be trusted to act. For agentic systems, digital trust must be continuous and cryptographically grounded, because behaviour can change after the initial login or handshake.
• Runtime Identity: An identity that must be governed while it is actively operating, not just when it is provisioned. For autonomous or semi-autonomous systems, runtime identity includes the ability to authorise actions, track behaviour, and remove access while the system is still in motion.
• Revocable Trust: A trust model in which access can be withdrawn immediately when behaviour changes, policy is violated, or mission scope ends. In agentic AI, revocable trust matters because safety depends on being able to stop action, not merely record that access once existed.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Keyfactor: Securing Agentic AI: Why Businesses Should Care. Read the original.