Agent security is becoming identity governance with a faster runtime

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Newcore's blog post: AI agent security is being framed around familiar identity controls, with discovery, just-in-time access, runtime authorization, and revocation emerging as the core pattern.

Why it matters: This matters because IAM, PAM, and governance teams are being asked to apply controls designed for people and service accounts to agents that move faster, act more often, and may span multiple systems.

By the numbers:

• 79% of enterprises run AI agents in production and 2% have deployed purpose-built identity security for them, according to Newcore.

Context

AI agent governance starts with a basic identity question: what exists, who owns it, and what can it do? When an organisation cannot enumerate agents, the rest of the control stack is already late, because policy, approval, and revocation all depend on an authoritative inventory. That is the same structural problem teams face with unmanaged service accounts, except agents can change scope faster and across more tools.

The current wave of agent controls is therefore less about inventing new security primitives and more about reapplying NHI lifecycle governance to a more dynamic actor. The governance gap is not the lack of ideas. It is the failure to treat agent identity as something that needs ownership, scope, and offboarding from the start.

Key questions

Q: What should teams do when an AI agent is found outside governance?

A: They should contain the access path before expanding the agent’s reach, then assign ownership, review the connected secrets and roles, and decide whether the integration belongs in scope at all. The important issue is not just removing access, but deciding whether the identity should have existed in production in the first place.

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

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: Why do just-in-time access controls matter for non-human identities?

A: JIT matters because it reduces the time a secret, token, or privileged session remains usable. For NHIs, that shortens the blast radius of compromise and reduces unnecessary standing access, but only if the credential lifetime and downstream revocation are enforced as part of the same control.

Q: How should teams revoke an agent's access across multiple systems?

A: Revoke the agent’s delegated authority centrally by disabling its identity, such as its service account, token, API key, or certificate, and then remove its tool entitlements in every connected system. A proper kill switch also stops scheduled jobs, rotates any exposed secrets, and records the human owner who authorised shutdown so the access cannot reappear through a cached session or shadow integration.

Technical breakdown

How agent discovery changes the identity inventory problem

Agent discovery is not a search problem alone. In identity terms, it is the mechanism that turns an unknown runtime actor into a governable object with an owner, scope, and policy path. Discovery has to cover sanctioned and unsanctioned agents, short-lived scripts, browser-based automations, and agents created outside central IT. Without that baseline, approvals and revocation operate on assumptions instead of facts. The real architectural issue is that the control plane cannot certify or terminate what it cannot enumerate. That is why inventory is the first control, not a preparatory nice-to-have.

Practical implication: Treat agent discovery as a prerequisite for governance coverage, not as a reporting feature.

Why just-in-time access for agents is closer to PAM than to app onboarding

Just-in-time access for agents is a privilege model, not a workflow convenience. The objective is to eliminate standing authority by issuing access only for the task, the context, and the minimum duration needed. That is the same logic as privileged access management for human admins, but agents compress the event window and increase the number of decisions. If access persists after the task, the control has failed even if the login succeeded. In practice, this shifts the control point from provisioning to issuance and from broad role assignment to narrowly scoped transaction-level authorization. See the Just-in-Time Access and Zero Standing Privilege Guide.

Practical implication: Design agent access so privilege expires with the task, not with the account.

How runtime authorization and revocation work across connected systems

Runtime authorization evaluates each action at the moment it is requested, which is why it is better suited to agents than a one-time login check. A policy decision point can allow, challenge, or block an action based on context, but the design only works if the revocation path reaches every system the agent can touch. Shared revocation signals matter because a kill switch that lives inside one product does not solve cross-platform drift. The architecture challenge is not permission checking alone. It is making enforcement and termination follow the agent across gateways, connectors, and downstream tools. See the Privileged Access Management Guide.

Practical implication: Map every path an agent can use before you assume a kill switch will actually stop it.

Threat narrative

Attacker objective: The objective is to let an agent continue acting beyond intended scope long enough to reach data, tools, or workflows that should have been out of bounds.

1. Entry occurs when an approved or unsanctioned agent is created and begins operating with access that has not been fully scoped or discovered.
2. Escalation happens when the agent retains standing authority or gains broader permissions than the specific task requires, especially across multiple connected systems.
3. Impact follows when the agent can keep acting, request new work, or outlive revocation in one control plane while still reaching other paths the organisation did not close.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

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

Agent security is really identity governance under runtime pressure. The controls being discussed are familiar because the governance problem is familiar: enumerate the actor, bound its authority, monitor its actions, and revoke access when the task is done. What changes is the tempo, not the discipline. Teams that already manage service accounts, privileged sessions, and access reviews are closer to readiness than the market language suggests.

Identity inventory becomes the decisive control when the actor is an agent. Discovery is no longer just about reducing blind spots. It is what makes ownership, policy assignment, and revocation possible at all. The absence of inventory is therefore a governance failure, not an observability gap, and it leaves the organisation unable to prove what existed when the agent acted.

Standing privilege is a broken assumption for autonomous runtime behaviour. Access review processes were designed for identities whose permissions persist long enough to be observed, certified, and removed later. That assumption fails when an agent acquires and releases access within a single task cycle because there may be no durable state to review after the fact. The implication is that governance has to shift from periodic certification to issuance-time control.

Cross-platform revocation is now part of the control design, not an implementation detail. A kill switch that only terminates one vendor path does not solve delegated access that continues through other connectors, native integrations, or unmanaged tools. Newcore's article points to the core truth: the chain of delegation matters as much as the agent itself. Practitioners need revocation that follows the actor, not just the platform.

Agent governance will converge on the same accountability pattern used for human privileged access. Someone must own the agent, someone must be accountable for its permissions, and the chain of delegation must be recorded. The field is moving toward identity records that connect the agent, the user it acts for, and the policy that allowed each action. That is the governance model practitioners should expect to operationalise.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Service Account Security Guide

What this signals

Runtime governance will replace many of the assumptions embedded in periodic access review. When the actor can request, use, and release privilege inside a single work cycle, the programme cannot wait for the next certification round to notice a problem. The practical shift is from proving access later to constraining every action as it happens.

Agent identity will increasingly be managed as a delegation chain, not a single account. Organisations will need to know which human, application, and policy path authorised each action, because that chain is what determines accountability after an incident. Without that record, revocation and audit become reconstruction exercises rather than controls.

Least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. That gap shows why agent scope is not a cosmetic policy choice. Security teams that let agents accumulate broad permissions will inherit the same failure pattern seen in other over-privileged identity estates.

For practitioners

• Build an authoritative agent inventory Connect discovery to identity providers, AI platforms, and workflow entry points so sanctioned, unsanctioned, and orphaned agents are visible before policy is applied.
• Replace standing agent access with task-scoped issuance Issue access only for the action being performed, attach a reason or approval condition, and ensure the token expires as soon as the task completes.
• Record the human owner and delegated user for every agent action Log each request, decision, and approval with the agent identity, the human accountable for it, and the user on whose behalf it acted.
• Test revocation across every path an agent can use Validate that disabling the agent in one control plane also closes native connectors, direct application paths, and any managed-device route the agent can still reach.
• Scope policy at the action level Define which actions are allowed, blocked, or require approval so a single agent can read, search, send, or change settings under different rules.

Key takeaways

• AI agent security is collapsing into a familiar identity problem: discover the actor, constrain its privilege, and revoke access cleanly when it is done.
• The hardest failures are governance failures, especially when agents exist outside inventory or keep acting after their intended scope ends.
• Practitioners should treat runtime authorization and revocation as part of the identity control plane, not as add-ons to a product rollout.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs · Service Account Security Guide · Just-in-Time Access and Zero Standing Privilege Guide · Privileged Access Management Guide

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Just-in-Time (JIT) Access: Just-in-Time (JIT) Access grants permissions only when needed and removes them after use. In IAM and PAM, it reduces standing privilege by issuing time-bound access based on approval, context, or policy, limiting exposure for humans, service accounts, and non-human identities while improving auditability and control.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.

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 IAM programme, it is worth exploring.