AI agent security needs runtime visibility, not new security models

At a glance

What this is: This is a practitioner analysis of AI agent security that argues existing security strategies still apply, but they need agent-specific visibility and enforcement to cover reasoning, retrieval, tool use, and action paths.

Why it matters: It matters because IAM, PAM, and security operations teams need to govern AI agents as non-human identities with real system access, audit trails, and blast radius limits.

By the numbers:

• 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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Zenity’s analysis of AI agent security and governance

Context

AI agent security is not a reinvention of cybersecurity, but it does expose a governance gap that older control models do not cover well. The issue is visibility across the full agent lifecycle, from what triggers the agent to what it retrieves, which tools it calls, and which actions it takes. For identity and access teams, that means treating agents as governed non-human identities rather than as ordinary automation.

Zenity’s core argument is that teams already own many of the right control categories, including risk assessment, posture management, detection, containment, and response. What changes is the need to extend those controls into agent-specific decision chains and audit trails, so security teams can see both the reasoning path and the action path.

The article frames three deployment shapes, SaaS-managed, home-grown, and device-based agents, which is a useful reminder that governance requirements will vary by ownership model and operating context. That starting point is typical for organisations trying to operationalise AI agent security without overfitting controls to a single vendor stack.

Key questions

Q: How should security teams govern AI agents that can call enterprise tools?

A: Security teams should govern AI agents the same way they govern sensitive non-human identities, but with added runtime visibility. That means mapping every trigger, tool, and action, then enforcing least privilege, approval boundaries, and audit logging across the whole decision chain. If a team cannot reconstruct what the agent did, it cannot prove the agent was safe.

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

A: AI agents create more risk because they can reason, retrieve context, choose tools, and execute actions dynamically. Ordinary automation follows predefined paths, but agents can be steered by poisoned memory, tainted knowledge, or trigger abuse. That makes access scope and action logging far more important than with static workflows.

Q: What breaks when AI agent activity is not logged end to end?

A: End-to-end logging is what lets teams reconstruct trigger, retrieval, tool use, and action. Without it, security teams lose the chain of custody for agent decisions, which makes containment, investigation, and accountability much harder. In practice, missing logs turn an agent incident into an unexplained business event.

Q: Who should own AI agent governance in an organisation?

A: AI agent governance should sit with identity, security architecture, and risk owners together, because the controls span identity, telemetry, policy, and operational response. If ownership sits only in AI engineering, the programme usually misses entitlement design and audit requirements. If it sits only in IAM, it usually misses runtime behaviour.

Technical breakdown

How AI agent attack surfaces emerge across memory, knowledge, tools, and triggers

An AI agent is not just a model with a chat interface. It combines memory, which can persist state, knowledge sources such as documents or retrieval systems, tools such as APIs or plugins, and triggers that start work from a prompt, webhook, message, or schedule. Each layer creates a distinct exposure point. Memory can retain poisoned instructions, knowledge sources can be tampered with, tools can be over-permissioned, and triggers can be abused to start unsafe workflows. The security challenge is that the attack surface spans both content and execution, so controls must examine the full chain, not only the prompt or model output.

Practical implication: map every agent to its memory, retrieval, trigger, and tool dependencies before granting production access.

Why traditional security tools miss AI agent behaviour and audit trails

Traditional controls can observe infrastructure, identities, or network events, but they often cannot reconstruct the agent’s full decision chain. If a tool call follows a retrieval step and ends in a write action, that sequence matters for security analysis, yet it may be invisible in separate logs. This is why agent security needs purpose-built telemetry that captures what initiated the agent, what it retrieved, which tools it used, and what action followed. Without that path-level visibility, teams can detect a breach only after the agent has already acted.

Practical implication: require activity-path logs that connect trigger, retrieval, tool invocation, and action into one audit trail.

Agent-centric security as a lifecycle control plane

Agent-centric security treats the agent as the entity to govern across its lifecycle, not just the model or interface. That means checking posture before deployment, enforcing policy at runtime, and preserving logs that show how behaviour changed over time. This approach aligns with least privilege, segmentation, continuous monitoring, and incident response, but applies them to agent behaviour rather than static accounts alone. The important point is that governance must follow the agent across model changes, connector changes, and workflow changes.

Practical implication: evaluate controls that can govern the agent across build time and runtime, not only at initial setup.

Threat narrative

Attacker objective: The attacker wants the agent to execute unsafe actions at machine speed while appearing to follow legitimate workflow logic.

1. Entry occurs when a trigger such as a prompt, webhook, or schedule starts an AI agent workflow and brings it into a sensitive enterprise context.
2. Escalation happens when the agent retrieves tainted knowledge, follows injected instructions, or invokes over-permissioned tools that expand its effective access.
3. Impact follows when the agent performs write actions, bulk changes, or quiet policy violations that look like normal work but affect real data and systems.

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

AI agent security is a non-human identity problem before it is an AI problem. The article correctly shows that agents touch sensitive systems, invoke tools, and produce actions that create real enterprise risk. That makes identity, entitlement scope, and auditability the governing questions, not model sophistication. The practical conclusion is that agent governance belongs inside identity and access programmes, not beside them.

Runtime visibility is the control gap that determines whether AI agent governance is real or rhetorical. If a team cannot see what triggered the agent, what it retrieved, which tools it called, and what it did next, it does not have meaningful accountability. The article’s strongest point is that these paths are where abuse hides. Practitioners should treat path-level telemetry as a prerequisite for governable agent behaviour.

Reasoning path and action path are now separate security objects. Traditional controls were built around permissions and outputs, but AI agents introduce an intermediate decision layer that can be manipulated before any final action occurs. That means policy enforcement at the model boundary is insufficient on its own. The field needs governance that links decision context to executable privilege.

Runtime authority drift: AI agents can expand effective access through trigger abuse, tool misuse, and unsupervised action sequencing even when the original permission set looked narrow. That is a structural governance problem, not just a misconfiguration. The implication is that teams must stop assuming static privilege descriptions fully represent the agent’s real operating scope.

AI agent governance will increasingly converge with enterprise lifecycle discipline. The article’s deployment shapes, posture checks, and runtime enforcement logic all point to the same reality: agents need onboarding, scope review, monitoring, and removal just like other governed identities. That is especially true where agents are configured across SaaS, home-grown, and local environments. Practitioners should plan for lifecycle control across the full agent estate.

From our research:

• 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, according to AI Agents: The New Attack Surface report.
• Only 44% have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
• That policy gap is the reason teams should pair agent telemetry with identity controls and start with the OWASP Agentic AI Top 10 as a practical risk lens.

What this signals

Runtime authority drift: AI agent programmes fail most often when teams assume a prompt boundary is also a privilege boundary. The practical test is whether your IAM and PAM stack can explain not just who started the workflow, but what the agent was able to do after it started.

The security architecture lesson is that build-time approval is not enough. If a team is serious about agent governance, it needs continuous observation of tool use, data retrieval, and write operations, plus clear escalation paths when behaviour exceeds expected scope.

For teams formalising controls, the next step is to align agent governance with established guidance such as the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework. That combination helps convert abstract concern into control design.

For practitioners

• Inventory every agent trigger and tool path Document which prompts, webhooks, schedules, and inter-agent messages can start work, then list the tools each agent can call and the actions each tool can perform. This gives security teams a control map before production rollout.
• Separate model safety from enterprise authorization Use model controls for unsafe content reduction, but rely on enterprise identity, entitlement, and policy controls for tool access and write permissions. Model-level safety alone does not govern downstream execution.
• Require activity-path audit logs Capture trigger, retrieval, tool invocation, and final action in one trace so responders can reconstruct how the agent reached a decision. Without that chain, incident review becomes guesswork.
• Treat agent deployment types differently Apply different governance requirements for SaaS-managed, home-grown, and device-based agents because ownership, configuration depth, and control boundaries are not the same. One policy template will not fit all three.

Key takeaways

• AI agent security is fundamentally an identity and access governance problem because agents act on real systems, not just on text.
• The biggest operational weakness is lack of full-path visibility, which leaves security teams unable to explain how an agent reached a harmful action.
• Teams should govern triggers, tools, and actions together so agent behaviour stays within intended scope across the entire lifecycle.

Key terms

• AI Agent: A software entity that can decide what to do, select tools, and execute actions against systems or data. In governance terms, the important issue is not intelligence alone but the scope of action, the visibility of the decision chain, and whether access can be explained after the fact.
• Activity-Path Visibility: A complete trace of what started an agent, what it retrieved, which tools it used, and what it did next. This is the difference between seeing a prompt and understanding behaviour, and it is essential for audit, investigation, and control validation.
• Agent-Centric Security: A control approach that treats the agent itself as the governable entity across build time and runtime. It focuses on posture, policy, telemetry, and behavioural boundaries so security teams can manage the agent’s real operating scope rather than only the underlying model.
• Runtime Enforcement: Policy enforcement that happens while the agent is operating, not just before deployment. For agentic systems, runtime enforcement matters because tool calls, retrieval results, and action timing can change after approval, which creates risks that static review cannot catch.

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 responsible for identity security strategy or operational governance, it is worth exploring.

This post draws on content published by Zenity: Demystifying AI Agent Security. Read the original.