Securing AI agent actions, not prompts, is the real control shift

At a glance

What this is: This Gartner research says AI security must move from prompt filtering to runtime control of AI agent actions, because autonomous agents create identity and access risk across tools and enterprise systems.

Why it matters: For IAM and NHI practitioners, the implication is that agent identity, authorization, and discovery now sit at the center of AI governance, not content moderation alone.

By the numbers:

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

👉 Read Astrix Security's analysis of Gartner's agent action security guidance

Context

AI agent security is no longer a content-moderation problem. When an autonomous agent can call tools, hold tokens, and act across enterprise systems, the security question shifts from what it said to what it can do. That is why this report matters for NHI governance: the identity attached to an agent is now part of the control surface, not just the application stack.

Gartner’s argument is that prompt filters were built for conversational AI, while agentic systems create runtime risk through tool use, state, and delegated access. That distinction is familiar to IAM teams, but still under-implemented in AI programs. The practical challenge is to govern machine identity, permissions, and action approval in real time, not after a prompt is processed.

For teams already exploring agentic workflows, this is a typical maturity gap. Most organisations can describe prompt controls more easily than they can enforce action-level authorization, discovery, and least privilege for non-human identities. The report treats that gap as structural, not temporary.

Key questions

Q: How should security teams govern AI agents that can take actions across enterprise systems?

A: Security teams should govern AI agents as non-human identities with scoped permissions, named ownership, and runtime policy checks on meaningful actions. That means inventorying agent-to-tool paths, limiting access to the minimum required systems, and approving high-risk actions at execution time. If the agent can act, it needs the same access discipline that applies to any privileged workload.

Q: What is the difference between prompt security and agent security?

A: Prompt security focuses on the text a model receives and generates, while agent security governs what an autonomous system can do with tools, credentials, and enterprise access. Prompt controls reduce unsafe language and data leakage. Agent controls reduce unauthorized action, privilege misuse, and blast radius. The two are related, but they solve different problems.

Q: When does just-in-time access make sense for AI agent governance?

A: Just-in-time access makes sense when an agent needs temporary privilege for a bounded task and the workflow can tolerate explicit approval or time limits. It is most useful when the default entitlement would otherwise be broad or persistent. If the agent needs continuous access to core systems, JIT alone is not enough and should be paired with stronger authorization and monitoring.

Q: Why do autonomous agents complicate zero trust architecture?

A: Autonomous agents complicate zero trust architecture because they can move across systems, call tools, and reuse delegated credentials without a human in the loop at every step. ZTA assumes continuous verification, but agents often create rapid chains of machine-to-machine action that need policy enforcement at runtime. Identity, context, and action approval must all be verified.

Technical breakdown

Why prompt filtering fails for autonomous AI agents

Prompt filtering inspects text before or after a model response, which works only when the model is the primary actor. Autonomous agents are different because they persist state, make multi-step decisions, and invoke external tools or APIs. Once an agent can write, delete, retrieve, or trigger actions in enterprise systems, the security problem becomes authorization, not language safety. Text classifiers cannot reliably detect tool misuse, permission creep, or credential abuse inside an execution loop. That is why runtime controls must sit closer to identity and policy enforcement than to content moderation.

Practical implication: Treat prompt safety as a limited control and move the security boundary to agent execution and authorization.

Identity, access, and runtime policy for AI agents

An AI agent behaves like a non-human identity with delegated authority, which means it needs a lifecycle, scoped permissions, and traceable accountability. In practice, this includes discovery of agents and associated secrets, mapping each agent to an owner, and constraining actions with least privilege and step-up approval where needed. Runtime policy matters because the agent’s risk is not static. Its context, tool access, and decision path change as tasks progress, so controls must evaluate every meaningful action rather than only initial authentication.

Practical implication: Build agent IAM around scoped identity, ownership, and action-level policy checks rather than one-time enrollment.

MCP security and the agent tool chain

Model Context Protocol links agents to tools and data sources, which makes it a high-value control point. If an attacker can abuse MCP connections, over-permissioned connectors, or unmanaged tool endpoints, the agent can be redirected into unauthorized data access or destructive operations without breaking the model itself. The risk is not limited to the model layer. It extends across connectors, secrets, service accounts, and the policies that govern how the agent reaches external systems. That is why MCP security and NHI governance need to be treated as one problem.

Practical implication: Inventory agent-to-tool paths and enforce policy on the connectors, credentials, and permissions that enable them.

Threat narrative

Attacker objective: The attacker wants to turn delegated AI agent access into a scalable path for unauthorized system actions, sensitive data exposure, or credential abuse.

1. Entry occurs when an attacker abuses over-permissioned agent access, compromised credentials, or an unmanaged tool connection to reach the execution path.
2. Escalation follows when the agent inherits broad permissions and can invoke additional tools, retrieve data, or trigger privileged actions beyond the original task scope.
3. Impact lands when the agent performs unauthorized system changes, data exposure, or credential abuse at machine speed across connected enterprise systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt security is now a subset of AI security, not the definition of it. The report is correct to separate conversational controls from agentic controls, because the latter depend on identity, authorization, and tool governance. That shift mirrors what IAM practitioners already know from service accounts and workloads: once a system can act, the question is who or what granted it that authority. The practitioner conclusion is simple. Secure the action path, not just the text path.

Agent identity creates a new blast-radius problem. When an autonomous agent can reach multiple tools and systems, the permissions attached to that agent define how far a mistake or compromise can spread. That makes discovery and entitlement review central to AI governance, especially where agents are layered on top of existing service accounts and API keys. The field needs to stop treating agent identity as an implementation detail. The practitioner conclusion is to map every agent to its effective access scope.

MCP will become a governance chokepoint if teams do not model it that way. Connector security, secret handling, and policy enforcement are converging around the same runtime path, which means agent tool access is now a primary control plane. This is why AI governance cannot sit only with model teams or only with IAM teams. The practitioner conclusion is to align both groups around shared enforcement for tools, credentials, and action approvals.

Guardian agents are a symptom of control failure, not a substitute for governance. Supervisory layers can help detect rogue behavior, but they do not remove the need for ownership, least privilege, and policy-backed runtime controls. The market is moving toward layered oversight because current controls are insufficient for autonomous action. The practitioner conclusion is to treat guardian agents as compensating controls, not the core security model.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap will widen if deployment keeps accelerating, so teams should pair discovery with policy enforcement before agent populations outgrow existing IAM controls.

What this signals

Ephemeral credential trust debt: when agents receive short-lived access without tight task scoping, the organisation accumulates hidden trust assumptions that are easy to miss in access reviews. That debt becomes visible only after a tool call, connector chain, or downstream system change reveals how much access the agent really had. Pairing agent controls with the NIST AI Risk Management Framework helps teams formalise ownership and oversight before those assumptions harden into operating practice.

As agent deployment expands, programme risk will shift from model evaluation to entitlement governance and auditability. The strongest indicator to watch is whether security, IAM, and application teams share a single view of agent identity, tool access, and approval paths. Where that view is fragmented, shadow AI and over-permissioned connectors tend to emerge first, especially in fast-moving development environments.

A practical operating model will treat each agent as a governed workload with a lifecycle, not a conversational feature. That means discovery, onboarding, entitlement review, and retirement need to be built into the same process that governs service accounts and other non-human identities. Teams that align those controls early will be better positioned to adopt agentic systems without expanding their attack surface uncontrollably.

For practitioners

• Implement agent discovery across all environments Build a complete inventory of AI agents, MCP servers, service accounts, API keys, and shadow AI paths before expanding deployment. Without discovery, you cannot assign ownership, scope permissions, or investigate misuse.
• Scope every agent to a named owner and task boundary Assign an accountable owner to each agent and define the business task, allowed systems, and maximum privilege set in writing. Review those boundaries whenever the agent gains a new tool or data source.
• Enforce runtime authorization for agent actions Require policy checks before high-risk actions such as data export, record updates, credential use, or connector changes. Keep approvals close to execution so policy decisions reflect current context, not stale enrollment data.
• Reduce excessive permissions on agent-linked identities Audit service accounts, tokens, and certificates used by agents and remove broad access that is convenient but unnecessary. Pair that work with secret rotation and short-lived access where the workflow allows it.
• Monitor MCP and connector activity as a security signal Log tool calls, connector changes, and failed authorization attempts so you can detect drift, misuse, and hidden dependencies. Treat unusual connector behavior as evidence of a control problem, not just an application issue.

Key takeaways

• AI agent security is an identity and authorization problem, not a prompt-filtering problem.
• Agent permissions define blast radius, so discovery and entitlement review are now core controls.
• Organisations should move runtime policy closer to execution before autonomous agents outpace existing IAM governance.

Key terms

• Agent Identity: An agent identity is the non-human identity used by an autonomous software entity to authenticate, access tools, and perform actions. It needs ownership, scoping, and lifecycle controls because the identity can reach enterprise systems without a human present at every step.
• Runtime Authorization: Runtime authorization is the policy decision made at the moment an action is about to occur. For AI agents, it determines whether a tool call, data access, or system change should proceed based on current context, not just the agent's original login or enrollment state.
• MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised identity can cause across connected systems. For AI agents and other NHIs, it is shaped by permissions, connector reach, and runtime approval controls, making entitlement scope a primary risk variable.

What's in the full article

Astrix Security's full post covers the operational detail this post intentionally leaves for the source:

• How Astrix maps AI agents, MCP servers, and non-human identities into one discovery workflow
• Which runtime access governance capabilities the vendor associates with safe agent deployment
• How the article frames controlled deployment and threat detection for enterprise agent adoption
• The vendor's positioning on policy-based access control for agent execution paths

👉 Astrix Security's full post covers the discovery, access governance, and runtime control details.

Deepen your knowledge

AI agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous systems and delegated access, it is a practical place to start.