Independent analysis by NHI Mgmt GroupSource article: Zenity, “Automation, Intent, and Ownership: What to Learn from the AI Agent Security Summit” (June 5, 2026)

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: NHI Mgmt Group's analysis, drawing on Zenity's blog post: AI agent security has shifted from point issues like prompt injection to a broader governance model built around intent, ownership, permissions and lifecycle control.

Why it matters: IAM, IGA and security teams need to understand that agent risk now spans authorisation, accountability and operational control, not just model safety or tooling hygiene.


Context

AI agent security is no longer only about stopping a single exploit path. As agents expand into browsers, open-source tools and shared knowledge sources, the governance problem becomes how intent, ownership and access boundaries are controlled across the full runtime path.

The article frames that shift as a lifecycle and accountability problem as much as a technical one. For identity programmes, the key issue is that the actor is not just using access, it is shaping actions across multiple systems with permissions that persist beyond a single prompt or task.


Key questions

Q: How should security teams govern AI agents that can change actions at runtime?

A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path. If the system can select tools or alter its sequence mid-session, a static access policy is not enough. The control objective becomes contextual verification of what the agent is doing, why it is doing it, and whether the data touched matches the approved purpose.

Q: Why do over-provisioned permissions make AI agents harder to secure?

A: Because the agent inherits broad access that was sized for a person, not for machine-speed execution or adversarial manipulation. If an attacker can redirect the agent, every extra entitlement increases the possible blast radius. The risk is highest when organisations copy employee roles into agents without re-scoping them to the actual task, environment, and approval model.

Q: What breaks when AI agent ownership is not tracked?

A: When ownership is not tracked, the agent can become orphaned after a role change or departure, leaving access active without a clear accountable person. That creates a lifecycle failure in the same way orphaned service accounts do. The result is weak revocation discipline and unclear responsibility.

Q: What should teams do when an agent is exposed to prompt injection or poisoned context?

A: Treat it as an access-control and containment problem, not only a content-safety problem. Revoke unnecessary permissions, isolate the workflow from sensitive systems and review every tool call the agent made under the manipulated context. Recovery should focus on preventing the same instruction path from reaching privileged actions again.


Technical breakdown

Why agent intent changes the security model

Agent intent is the runtime purpose or goal state that drives tool use, sequencing and action selection. In traditional IAM, authorization is usually evaluated at request time against a known subject and a bounded action. For AI agents, the security question changes because the system can interpret, reframe and pursue goals across multiple steps, which means the risk is not only what the agent is allowed to do but how it may transform a prompt into a sequence of actions. That makes intent a security variable, not just a product feature.

Practical implication: govern agent actions against intended outcomes, not only against static permission lists.

How ownership and permissions become a shared control problem

The summit material makes clear that AI agent risk is distributed across builders, operators and business owners. That matters because agent permissions often belong to one team, the workflow to another, and the data or identity scope to a third. Shared control becomes necessary when a single actor can span HR data, browser actions and external tools in one workflow. Without clear ownership, escalation paths and approval boundaries blur, which weakens accountability when the agent behaves outside expectation.

Practical implication: define who owns the agent, who owns the access, and who can stop execution when scope changes.

Why persistent permissions expand the attack surface

Agents with persistent access create a standing risk window that is larger than a human session and harder to reason about than a simple API call. When an agent can be influenced through prompt injection, skill abuse or poisoned inputs, the attack is not limited to one tool. It can reach everything the agent can reach until that access is removed or constrained. This is why persistent permissions combined with natural-language goal changes are so dangerous: the boundary between legitimate automation and misuse becomes much thinner.

Practical implication: reduce standing access for agents and review whether any workflow truly needs long-lived permissions.


Threat narrative

Attacker objective: The objective is to make the agent execute harmful actions or reveal sensitive data by abusing its legitimate runtime authority.

  1. Entry begins when an attacker or hostile input reaches an agent through prompt injection, skill abuse or another manipulated instruction path.
  2. Escalation occurs when the agent interprets the malicious instruction as part of its intended task and uses its existing permissions to act across connected tools or data sources.
  3. Impact follows when the agent carries out unauthorized actions, exposes sensitive information or performs operations the operator did not intend.

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

Intent has become a security control, not a UX layer: AI agents are no longer governed safely by static permissions alone because runtime behaviour can diverge from the initiating prompt. That means the control question is not just whether the agent was authorised to start, but whether its purpose remained bounded as it moved through tools, data and execution contexts. Practitioners should treat intent as an enforceable part of agent governance, not as an after-the-fact explanation.

Ownership must span the full agent lifecycle: The article shows why agent security fails when builders, security teams and business owners each assume someone else owns the risk. Lifecycle accountability is now a cross-functional requirement because the agent can act across systems that no single team fully controls. The implication is that identity governance for agents must include explicit ownership, escalation and shutdown authority.

Persistent permissions create identity blast radius: When an agent retains broad access across sessions, the attack surface extends well beyond the moment of task initiation. That persistence lets malicious instructions, poisoned context or skill abuse convert ordinary access into repeated unsafe action. Practitioners should read this as a governance problem of standing authority, not just a tooling problem.

Shared control is the new operating model for autonomous workflows: The summit’s real signal is that model security, application security, identity governance and endpoint control can no longer be managed as isolated disciplines when agents bridge them all. That makes the governance gap itself the risk surface. Teams should redesign oversight so the people who own the business outcome also own the control boundary.

Agent security now depends on understanding the path from intent to impact: The field is moving toward governance that explains why an agent acted, who approved the scope and where the access boundary was enforced. That is where security teams will separate bounded automation from uncontrolled delegation. Practitioners should prioritise controls that preserve traceability from goal to action to outcome.

From our research library:

What this signals

Intent becomes the governance hinge: Agent security is increasingly defined by whether the organisation can bind a runtime goal to a narrow, observable action scope. That is a different control problem from classic human IAM because the subject can reinterpret instructions mid-session and continue acting within valid access. The practical shift is toward controls that verify purpose, not just identity.

Shared control will shape the next phase of agent programmes: The more an agent crosses browser, app and identity boundaries, the less useful single-team ownership becomes. Security leaders should expect pressure to formalise approval chains, revoke paths and audit ownership for every production agent. Programmes that do not define this now will discover the gap during the first serious incident.


For practitioners

  • Define an explicit agent owner Assign one accountable owner for each production agent, including escalation authority, access scope approval and shutdown responsibility across its lifecycle.
  • Separate intent approval from execution access Require the business purpose and allowed action scope to be approved before the agent receives access to tools, data sources or browser workflows.
  • Reduce standing permissions for agents Review which workflows truly need persistent access and remove long-lived permissions where task-scoped or session-scoped access is sufficient.
  • Instrument agent actions for auditability Log prompt inputs, tool calls, decisions and downstream effects so security teams can reconstruct intent drift and scope expansion after the fact.
  • Test for malicious instruction handling Simulate prompt injection, poisoned content and skill abuse against agent workflows that touch sensitive systems, then verify containment before production use.

Key takeaways

  • AI agent security is moving from isolated exploit prevention to governance over intent, ownership and control boundaries across the full workflow.
  • Persistent permissions and cross-system access make agent misuse harder to contain because runtime influence can translate directly into privileged action.
  • Security teams need explicit ownership, narrow access and auditability if they want agent programmes to remain governable in production.

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 addresses the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article centres on agent permissions, ownership and misuse of runtime authority.
ASI09 — Human-Agent Trust ExploitationPrompt injection and manipulated goals exploit human trust in agent instructions.
ASI02 — Tool MisuseThe article discusses agents spanning browsers and tools that can be redirected at runtime.
Recommendation — Apply ASI03 to constrain agent privilege scope and separate ownership from execution rights. Map trust-based agent abuse to ASI09 and test workflows against malicious instruction paths. Use ASI02 to validate that agent tool access stays within approved task boundaries.
NIST AI RMFGOVERN — AI Governance and AccountabilityShared ownership, accountability and lifecycle control are central to the article.
Recommendation — Establish GOVERN processes that assign accountable owners and approval paths for each production agent.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsPersistent agent permissions and scope control are core to the article's governance problem.
Recommendation — Apply PR.AA-05 to minimise standing agent entitlements and review access scope continuously.

Key terms

  • Agent intent: The immediate goal implied by an AI agent’s current sequence of tool calls. Unlike static automation, intent can change at runtime, which is why identity governance for agents has to look beyond permission sets and toward execution-time behaviour.
  • Shared Control Model: A shared control model is a single operating control design that can satisfy multiple frameworks or requirements when they cover the same underlying activity. It reduces duplicate work, avoids conflicting process definitions, and lets one well-run control produce evidence that supports audits, customer requests, and risk decisions.
  • Persistent Permission: An access grant that remains available across sessions or tasks instead of expiring after a single use. For AI agents, persistent permission expands the blast radius of prompt injection, goal manipulation and tool misuse because the same authority can be reused repeatedly.
  • Intent Drift: A mismatch between the original purpose of an agent session and the outcome produced by a later chain of actions. It matters because each step can be individually permitted while the overall behaviour still becomes unsafe or non-compliant.

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 building or maturing an identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org