TL;DR: At the AI Agent Security Summit, the central finding was that agentic workflows now span browsers, open-source tools, identities and knowledge sources, while persistent permissions and natural-language goal changes keep expanding the attack surface, according to Zenity. Security teams now need a governance model that treats intent, ownership and lifecycle controls as one system, not separate workstreams.
At a glance
What this is: This summit recap argues that AI agent security has shifted from isolated technical hardening to a governance problem centred on intent, ownership and shared responsibility.
Why it matters: It matters because IAM, NHI and autonomous governance programmes now have to control what agents can reach, how they are directed and who owns the risk when their behaviour crosses organisational boundaries.
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
👉 Read Zenity's analysis of the AI Agent Security Summit and agent ownership
Context
AI agent security is no longer just about stopping prompt injection or tool misuse. The broader issue is that agentic workflows now cross identity boundaries, data boundaries and operational boundaries in a single execution path, which makes traditional siloed controls too slow and too narrow for the risk being introduced.
That shift changes the governance question for NHI, autonomous and human identity programmes alike. Once agents can act across browsers, open-source tools and sensitive knowledge sources, organisations need to decide who owns the permissions, who reviews the intent and who is accountable when the agent behaves outside expectation.
Key questions
Q: How should security teams govern AI agents that can act across multiple systems?
A: Security teams should govern AI agents as identities with lifecycle ownership, scoped permissions and revocation paths. The practical issue is not just access control, but whether the organisation can explain who owns the agent, what it may reach and when its authority ends. Without those answers, the agent becomes an unmanaged execution path.
Q: Why do AI agents create more risk than ordinary automation?
A: AI agents create more risk because they can change their behaviour at runtime, react to prompts and continue acting with persistent permissions across multiple systems. Ordinary automation follows a predefined script. Agents can be influenced after deployment, which means governance must cover intent, context and accountability, not just the original workflow design.
Q: What do security teams get wrong about agent permissions?
A: Teams often treat agent permissions as a one-time setup choice, then forget that the same permissions can be reused in new contexts. That is a mistake because the agent’s task, data source and action path may change without a corresponding review. Permissions must be revalidated whenever the agent’s purpose changes.
Q: What should organisations do when an AI agent is no longer needed?
A: They should revoke the agent’s access, retire its credentials and confirm that its downstream integrations are disabled before the business use case is closed. If the identity stays active after the task ends, the organisation has created lingering authority with no live business owner behind it.
Technical breakdown
Persistent access turns agents into always-on identity risks
The article points to a core architectural problem: agents often retain broad permissions for long periods, which makes them reachable at any time. In NHI terms, that is similar to standing privilege, but with a more dynamic execution layer because the same identity can be redirected through new prompts, new skills or new browser actions. The risk is not just access breadth, but access persistence combined with context switching. Once an agent can hold privileges while its task changes, the blast radius expands beyond the original use case.
Practical implication: treat agent permissions as living entitlements with defined scope, review points and revocation paths, not as static setup decisions.
Intent is becoming an access control signal
Zenity’s framing around intent matters because agents can be manipulated through natural language in ways that traditional access models do not model well. Intent is not a policy token, but it is a security signal that helps explain why an agent is touching a system, a dataset or a workflow. That is especially important when model, application, identity and endpoint controls are all involved. If security teams cannot connect action to intent, they cannot reliably distinguish legitimate delegation from covert influence or abuse.
Practical implication: build traceability for prompts, actions and downstream effects so investigators can reconstruct why an agent did what it did.
Lifecycle security now spans builders, operators and permission owners
The summit’s strongest governance message is that lifecycle responsibility does not sit in one team. Builders define the skill or workflow, operators enforce boundaries, and permission owners control the identities the agent can reach. That creates a three-party accountability chain that is harder than classic service account governance because the agent’s behaviour can be altered after deployment without changing the underlying identity record. In practice, this is where human IAM habits, NHI controls and agent governance collide.
Practical implication: assign lifecycle ownership across build, approve and operate stages so no agent can remain active without a named control owner.
Threat narrative
Attacker objective: The attacker’s objective is to turn trusted agent access into broad unauthorised execution across data, systems and credentials without needing a separate privileged identity.
- Entry begins when an AI agent is placed into browsers, open-source tools or shared knowledge sources with broad standing permissions.
- Escalation occurs when attackers or malicious prompts override the agent’s goals in natural language, causing the agent to take actions outside its intended scope.
- Impact follows when the agent reaches sensitive data, unauthorised systems or credentials through the access it already holds.
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
Intent is becoming a governance control, not just a design concept. The summit makes clear that agent behaviour cannot be governed only through static role assignment or access review. When an identity can be redirected through prompts, skills or contextual inputs, intent becomes part of the control surface. The implication is that IAM and NHI programmes must treat action context as a first-class governance signal, not an after-the-fact forensic detail.
Persistent access is the new identity blast radius for AI agents. Agents are attractive to builders precisely because they do not require hard-coded instructions, but that convenience creates standing exposure. The article shows how broad, durable permissions let a compromised or misdirected agent touch far more of the enterprise than a conventional workflow would. Practitioners should read this as evidence that agent governance is fundamentally an access-scope problem.
Lifecycle security for agents fails when ownership is split across too many teams. The summit’s discussion of builders, operators and permission owners exposes a shared-accountability problem that is already familiar in NHI governance. Without a single lifecycle owner for the agent identity, policy drift becomes inevitable and revocation becomes ambiguous. Teams should treat this as a governance design issue, not a tooling gap.
Agent intent tracing is the named concept this market now needs. Agent intent tracing is the practice of linking prompts, permissions and resulting actions so security teams can explain why an agent acted, not just what it touched. That concept matters because human review cycles alone are too slow for agent-paced decisions. Practitioners should be designing for traceability across identity, data and execution layers now.
From our research:
- 98% of companies plan to deploy even more AI agents within the next 12 months, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data and revealing access credentials.
- Analysis of Claude Code Security shows how security teams are starting to treat AI-driven defence as an identity and governance problem, not just a tooling choice.
What this signals
With 98% of companies planning to deploy more AI agents in the next 12 months, the control gap is no longer theoretical. Persistent agent authority is now the design risk to watch, because most IAM and NHI programmes were built around identities whose purpose could be reviewed after the fact, not actors that can change behaviour mid-session.
Practitioners should expect lifecycle governance to move closer to build-time policy, especially where agents touch HR, customer or engineering data. The organisations that will cope best are the ones that can tie access, intent and ownership together before the agent reaches production, rather than discovering the gap after the first incident.
For practitioners
- Map agent ownership across build, approve and operate stages Assign a named owner for every AI agent identity, including who defines the workflow, who approves its permission scope and who can revoke it when behaviour changes. If those roles are split, document the handoff and the revocation path so accountability does not disappear when the agent moves from pilot to production.
- Constrain persistent permissions to the smallest workable scope Review whether each agent still needs the broad access it received at launch. Break out browser access, knowledge source access and system action access so one compromised workflow cannot automatically reach every downstream asset.
- Instrument prompt-to-action traceability Log the intent input, tool call and resulting system change for every meaningful agent action. This is what lets security, legal and operations teams reconstruct whether the agent followed delegated intent or was steered off course.
- Tie agent revocation to lifecycle events Add explicit offboarding triggers for paused projects, changed business owners and altered data access boundaries. An agent that remains active after its original purpose ends is a governance failure, not an operational quirk.
Key takeaways
- AI agent security is becoming a governance discipline because persistent permissions and runtime prompt influence can change what an identity does after deployment.
- The summit’s message is that ownership, intent and lifecycle controls now matter as much as model safety or tool filtering.
- Practitioners should build traceability and revocation into agent programmes early, because unmanaged agent authority quickly becomes enterprise blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agents can have prompts and tools redirected at runtime, matching agentic abuse patterns. |
| NIST AI RMF | Agent ownership and accountability align to AI governance and lifecycle oversight. | |
| NIST CSF 2.0 | PR.AC-4 | Persistent agent permissions and lifecycle control are access management problems. |
Assign clear governance owners for agent behavior, access scope and revocation decisions.
Key terms
- Agent intent tracing: Agent intent tracing links the prompt, context, tool use and resulting action so teams can explain why an AI agent behaved a certain way. In practice, it is the difference between seeing activity and understanding delegated purpose, which is essential when agents can change behaviour at runtime.
- Persistent access: Persistent access is authority that remains valid across time instead of expiring with the task that needed it. For AI agents and other NHIs, persistent access increases blast radius because a single identity can be reused, redirected or abused long after its original business need has changed.
- Lifecycle ownership: Lifecycle ownership is the assignment of responsibility for creating, operating, reviewing and retiring an identity. For AI agents, this must include who defines the use case, who approves access, and who can revoke the agent when its purpose changes or its behaviour drifts.
Deepen your knowledge
AI agent lifecycle governance and access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are defining ownership for agent identities and permissions, it is worth exploring.
This post draws on content published by Zenity: Automation, Intent, and Ownership: What to Learn from the AI Agent Security Summit. Read the original.
Published by the NHIMG editorial team on 2026-06-05.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org