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.
NHIMG editorial — based on content published by Zenity: Automation, Intent, and Ownership: What to Learn from the AI Agent Security Summit
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Constrain persistent permissions to the smallest workable scope Review whether each agent still needs the broad access it received at launch.
- Instrument prompt-to-action traceability Log the intent input, tool call and resulting system change for every meaningful agent action.
What's in the full article
Zenity's full blog post covers the event detail this analysis intentionally leaves for the source:
- Session-by-session summit themes and speaker context from San Francisco
- The specific examples cited for prompt injection, MCP poisoning and agent persistence
- Zenity's own framing of how practitioners should interpret agent intent and ownership
- The event follow-up path for the later New York, EMEA and APAC summits
👉 Read Zenity's analysis of the AI Agent Security Summit and agent ownership →
AI agent security in 2026: what changed for ownership and control?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent security now depends on intent, ownership and shared control