Agentic security is about consequences, not just model prompts

At a glance

What this is: This is an analysis of why securing AI models does not secure AI agents, with the key finding that the risky part is the execution path from prompt to tool, API, and downstream action.

Why it matters: It matters because IAM, PAM, and governance teams must treat AI agents as runtime actors with delegated access, not just as chat interfaces, or they will miss the control points that actually create business impact.

👉 Read Salt Security's analysis of agentic security and execution-path risk

Context

Agentic AI changes the security problem because a system can now interpret intent, choose tools, and take action rather than only generate text. That means the main governance challenge is no longer limited to prompt safety or output filtering; it is access control, runtime visibility, and accountability across the full execution path.

For identity teams, the key question is how agent identities are authenticated, authorised, and constrained when they call APIs, reach data stores, or trigger workflows. For broader security teams, the issue is the same control gap seen in other workload contexts: the action path can be more dangerous than the conversation layer, and many environments do not instrument it well enough.

Key questions

Q: What breaks when security teams only filter prompts in agentic AI systems?

A: Prompt filtering only reduces conversational abuse. It does not stop an agent from calling tools, using APIs, or taking harmful downstream actions with valid credentials. If the execution path is ungoverned, a clean prompt can still produce a risky refund, data retrieval, or configuration change. The control gap is delegated privilege, not the text response.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed. Human session assumptions, periodic reviews, and static privilege models do not reflect that behaviour. The result is a governance gap between what was granted and what the agent can actually do.

Q: How can teams tell whether agentic access controls are actually working?

A: Look for evidence that every privileged action is logged with actor type, target resource, and policy decision, and that denied requests are being blocked before execution. If you can only see the login and not the downstream action, the control is too weak for agentic use.

Q: Who is accountable when an AI agent makes an unauthorised change?

A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.

Technical breakdown

Why prompt filtering does not secure agentic AI

Prompt filtering and output moderation address conversation risk, not action risk. A large language model can be safely prompted and still instruct a tool call that retrieves sensitive data, changes a record, or triggers a business workflow. In agentic systems, the model is only one component in a chain that also includes tools, APIs, orchestration logic, and backend systems. The security boundary therefore shifts from text inspection to control of delegated capabilities, authorisation, and runtime observation across the whole chain.

Practical implication: control the tools and APIs an agent can reach, not just the text it produces.

How the execution path creates agentic security risk

The execution path is the sequence from prompt to model decision to tool invocation to API call to downstream effect. Each hop can introduce a different failure mode. A tool may be over-permissive, an MCP server may expose a hard-coded secret, an API may lack rate limits, or a backend may assume the caller is a trusted human workflow. That is why agentic security needs code, configuration, and runtime telemetry together. Without all three, teams cannot tell what was built, how it is governed, or what actually happened.

Practical implication: instrument prompt, tool, and API telemetry as one traceable control plane.

Why identity matters for AI agents and MCP servers

AI agents are not just applications with a model attached. They often operate through machine identities, API keys, service accounts, and MCP servers that grant them real privileges. If those identities are over-scoped or poorly governed, the agent can act far beyond the intent of the request that triggered it. This is where agentic AI intersects directly with IAM and NHI governance. The same core questions apply: who or what is the actor, what can it reach, and how quickly can access be revoked or constrained when behaviour changes?

Practical implication: bind agent behaviour to scoped identities and review them like any other high-risk NHI.

NHI Mgmt Group analysis

Agentic security is a governance problem, not a prompt-moderation problem. The article correctly draws a line between conversation safety and action safety. That line matters because enterprises can have strong prompt controls and still allow dangerous tool calls, refunds, data exports, or configuration changes. The real failure mode is assuming that model safety equals system safety. Practitioners should treat agentic AI as an access-governed workload, not a chat interface.

Execution-path visibility is the named control gap that most teams still miss. The article's strongest insight is that the path from prompt to tool to API to downstream action is where risk accumulates. That is a distinct governance layer, and it is often invisible to traditional AI filters or static inventory tools. In identity terms, the agent's delegated privilege is the asset that must be observed and constrained. The practical conclusion is that runtime evidence, not policy intent, has to become the source of truth.

Agentic AI creates a new form of NHI sprawl. As agents begin using service accounts, API keys, and MCP servers to do real work, they become non-human identities with business-impacting authority. That means IAM and PAM teams need to decide whether the agent is acting as a workload, a delegated user, or a hybrid actor with multiple trust boundaries. The discipline now is not naming more AI controls, but extending identity governance to the agent runtime.

Visibility, governance, and runtime protection are three different control layers. The article usefully separates them, and that separation maps well to how security programmes fail. Inventory without enforcement is not protection, and policy without telemetry is not governance. Teams need to know which layer is missing before they assume they have coverage. The practitioner takeaway is to close the gap between configuration review and live action monitoring before agents scale further.

Agentic security will converge with workload identity standards and zero trust thinking. The broader market will move toward authenticating agents, constraining their tools, and validating each action in context rather than trusting the app shell around them. That aligns with identity-centric security models, but only if teams stop treating agents as exceptional software. Practitioners should expect governance pressure to move from prompt policy to identity, privilege, and runtime controls.

What this signals

Agentic AI is forcing security teams to move from content moderation to delegated access governance. The practical signal is that inventories of models and prompts will not be enough if the agent can already call tools, reach APIs, and mutate business systems. Teams should align runtime monitoring with identity evidence and pair it with the NIST AI Risk Management Framework so accountability is visible before the next scaling wave.

Execution-path governance: this is the control model emerging around agentic systems, where the unit of risk is not the response but the full chain of action. That means security leaders need to know which identities the agent uses, which tools they unlock, and which actions are irreversible. If that chain is not traceable, the programme is not ready for autonomous scale.

Identity and AI governance are converging around the same operational question: who can act, under what context, and with what evidence trail. For identity teams, the immediate priority is to treat agent identities like high-risk NHIs and review them with the same discipline used for service accounts and privileged automation. For AI security teams, the next step is to map those identities to runtime controls, not just policy documents.

For practitioners

• Define agent identities explicitly Assign each AI agent a distinct machine identity, scope its permissions to the smallest viable tool and API set, and separate production agents from testing and support workflows. This makes revocation and audit practical when behaviour changes.
• Trace the full execution path Log prompt input, tool selection, API request, returned data, and final action as one continuous record so investigators can reconstruct what happened without guessing. Treat the prompt and the action as linked evidence, not separate events.
• Restrict high-impact actions behind additional controls Require step-up approval, policy checks, or human confirmation for refunds, account updates, configuration changes, and data exports even when the request originates from an agent. Keep those controls outside the model so they still apply if the agent is manipulated.
• Review MCP and API exposure as privilege surfaces Inventory MCP servers, internal APIs, and any hard-coded credentials used by agent workflows, then reclassify them as privileged access paths. Revoke anything that can reach sensitive systems without a documented business need.

Key takeaways

• Agentic AI changes the security boundary from conversation safety to action safety, so prompt filters alone do not govern real risk.
• The critical failure mode is invisible execution paths where agents can use tools, APIs, and machine identities to change systems or move data.
• Identity governance, runtime telemetry, and privilege scoping must be applied to AI agents as a single control problem.

Key terms

• Agentic security: The practice of governing software actors that can choose actions, tools, and timing in production workflows. It extends identity, authorization, logging, and lifecycle control to agents so their behaviour is tied to a verifiable principal and a revocable permission set.
• Execution Path: An execution path is the chain of systems, roles, functions, and permissions that an identity uses to reach a target service. For AI agents, this matters more than the label on the agent itself because effective authority often comes from the path, not the object.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• A fuller explanation of how agentic security differs from conversation-layer AI controls in production environments.
• The article's own framing of visibility, governance, and runtime protection as separate control layers for agents.
• More detail on the agentic graph, including code, configuration, and runtime as distinct evidence sources.
• Salt's assessment workflow for mapping an agentic attack surface in practice.

👉 Salt Security's full post covers the agentic graph, tool-level governance, and runtime protection gaps in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It gives security and identity practitioners a shared foundation for governing delegated access across modern workloads.