What should organisations do when their agent identity model cannot explain behaviour?

Why This Matters for Security Teams

When an agent identity model cannot explain behaviour, the problem is usually not the label on the identity. It is the gap between a claimed identity and the action being taken at runtime. Autonomous systems can chain tools, change intent mid-session, and produce outcomes that a static IAM model was never designed to interpret. Current guidance suggests security teams should treat this as a control-plane problem, not just an authentication problem, and align response with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.

The operational risk is simple: if the control layer only knows who the agent is, but not what it is doing, the organisation cannot distinguish legitimate automation from suspicious automation. That is why NHI governance must extend beyond secrets hygiene and lifecycle checks, even though NHI exposures remain common across enterprises. NHI Management Group research shows that the Ultimate Guide to NHIs found 97% of NHIs carry excessive privileges, which becomes more dangerous when behaviour is opaque. In practice, many security teams encounter abnormal agent activity only after tool abuse or lateral movement has already begun, rather than through intentional runtime policy design.

How It Works in Practice

The practical response is to add policy at the point of action. Identity still matters, but only as one input to a runtime decision. A well-governed agent should present workload identity, such as cryptographic proof from OIDC, SPIFFE, or another workload identity system, then receive short-lived, task-scoped access based on the current context. That is very different from granting a standing role and hoping the agent behaves as expected.

Security teams should separate three layers:

• Identity proof: establish what the workload is, not just what account it uses.

• Intent or context evaluation: decide whether the requested action fits the approved task, destination, data sensitivity, and session state.

• Enforcement: challenge, throttle, or revoke access when behaviour drifts from the expected path.

That runtime decisioning is where policy-as-code becomes useful. Frameworks such as CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix help teams model how an agent may be manipulated, while the NHI view from 52 NHI Breaches Analysis shows why weak credential boundaries and poor visibility are repeatedly exploited. The goal is not to eliminate automation, but to make the control plane able to answer a harder question: is this action still consistent with the approved mission?

These controls tend to break down in environments where agents share credentials across multiple services, because shared authority destroys attribution and makes per-task revocation ineffective.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance safety against latency, tuning effort, and false positives. Best practice is evolving, and there is no universal standard for this yet, especially in multi-agent workflows where one agent triggers another and the original intent becomes harder to preserve.

Some environments need stronger throttling than others. High-trust internal copilots may tolerate broader approval windows, while external-facing or customer-data agents should use much narrower scopes and shorter TTLs. For regulated workloads, teams may also need to log every action that altered state, not just every authentication event, because identity logs alone will not explain a harmful decision.

That distinction matters when the model is not fully explainable. If the system cannot justify its behaviour, the safest path is to reduce standing access, issue ephemeral credentials per task, and require runtime checks before each sensitive action. NHI Management Group’s guidance in the Ultimate Guide to NHIs remains relevant here: visibility, rotation, and offboarding are necessary, but they are not sufficient when autonomy is the real risk driver. The same pattern appears in public reporting on agent abuse, including AI LLM hijack breach and the first reported AI-orchestrated intrusion analyses published by industry researchers. In practice, the edge case is not “unknown identity” but “known identity, unknowable next action.”

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations use a dedicated AI agent identity model or extend current NHI controls?
• What should organisations measure before consolidating identity and device administration?
• How should organisations align NIST CSF 2.0 with identity governance?