TL;DR: Agentic security is different from traditional AI security because agents call tools, access data, and change systems, turning a safe-looking conversation into a possible incident, according to Salt Security. Securing the model alone leaves the execution path, identity controls, and runtime authorisation gaps exposed.
At a glance
What this is: Salt’s analysis says agentic security is about controlling what AI agents do after a prompt, not just filtering what they say.
Why it matters: That matters because IAM, PAM, and AI governance teams now need to govern tool use, API access, and runtime actions, not only model outputs.
Context
Agentic AI changes the security boundary because the system is no longer only generating text. When an agent can call tools, reach APIs, and trigger workflows, the risk moves from conversation safety to action control. That is where traditional prompt filtering and output moderation stop being sufficient, especially when the agent is embedded in business processes and has access to real systems.
The identity angle is genuine here: agentic systems behave like software entities with delegated access, which means their privileges, tool permissions, and runtime authorisation become governance problems. The article’s core point is that teams can secure the model layer and still leave the execution path open, which is an IAM and NHI issue as much as an AI security issue.
Key questions
Q: What breaks when agent security stops at prompt filtering?
A: Prompt filtering only governs language, so it cannot stop an agent from using a legitimate tool or API to take an unsafe action. The failure mode is a clean conversation path with an uncontrolled execution path beneath it. Teams need authorisation at the moment of action, not only moderation at the moment of text generation.
Q: Why do AI agents create a different risk model than chatbots?
A: AI agents can act, not just generate. Once they can browse, retrieve, call tools, and complete tasks, the main risk shifts from unsafe output to unsafe action. That expands the attack surface from prompts to workflows, credentials, and downstream systems, which is why traditional model-only controls are no longer enough.
Q: How can security teams tell whether agent permissions are too broad?
A: The clearest signal is whether the agent can still complete its job after permissions are reduced in a sandbox. If the task keeps working after you remove broad access, the original entitlement was inflated. A second signal is the presence of unused permissions that persist across reviews and deployments.
Q: Should organisations treat agent identities like service accounts or end-user accounts?
A: Treat them like high-risk workload identities with tightly bounded permissions and explicit ownership. Agent identities are not casual user accounts because they may operate continuously, call tools automatically, and influence business systems at machine speed. Governance should cover lifecycle, scope, and runtime monitoring together.
Technical breakdown
Why prompt filtering does not secure agent actions
Prompt inspection and output filtering are controls for language safety, not action safety. They can reduce obvious jailbreaks, unsafe completions, and toxic responses, but they do not govern what happens once an agent is allowed to use a tool, invoke an API, or write back to a production system. In agentic architecture, the model becomes one decision point inside a larger execution chain. The security question shifts from “did the model say something bad?” to “did the system do something it was not authorised to do?” That requires policy at the action layer, not only the text layer.
Practical implication: Treat prompt controls as one layer only and place explicit authorisation checks on every tool invocation and downstream action.
The agentic graph connects code, configuration, and runtime
Salt’s framing points to three distinct control planes. Code reveals what was built, including hard-coded secrets, unsafe tool integrations, and missing checks. Configuration shows what is enabled, who owns the agent, and which APIs or tools it can reach. Runtime shows what the agent actually did, which is the only place you can verify whether its live behaviour matched its intended scope. For agentic security, these three views have to correlate. A clean policy document cannot compensate for an over-permissive tool path, and a dashboard without runtime evidence cannot tell you whether the agent crossed a boundary.
Practical implication: Correlate build, configuration, and runtime telemetry so agent actions can be reviewed against the permissions they actually used.
MCP and APIs turn identity into the control point
The article’s hand-and-buttons analogy is useful because it shows where agency becomes operational risk. MCP servers, APIs, and service accounts are the mechanism by which agents touch business systems. If those connectors are weakly authorised, over-scoped, or poorly inventoried, then the model can remain benign while the agent still alters records, issues refunds, or exposes data. This is where agentic AI meets NHI and IAM governance directly: the agent’s effective identity is the identity used to reach tools and services. Without tight lifecycle control, the delegation chain becomes the real attack surface.
Practical implication: Inventory every agent-to-tool and agent-to-API trust path, then constrain each path to the minimum actions required.
NHI Mgmt Group analysis
Agentic security is a runtime governance problem, not a prompt-safety problem. The article’s central claim is that the model layer can look clean while the execution path is still dangerous. That changes the control objective from filtering language to governing actions, which is where IAM, PAM, and NHI disciplines intersect most sharply. Practitioners should treat tool calls, API access, and downstream writes as the primary security boundary.
Execution-path risk is the named concept practitioners should adopt. In agentic systems, the dangerous path is not the conversation itself but the chain from prompt to tool to API to business outcome. This concept matters because it explains why conventional AI safety controls often miss the actual failure mode. Security teams need a vocabulary for the path, not just the model, if they want to govern autonomous behaviour credibly.
Agent identity must be governed as delegated authority. When an agent acts through MCP servers, APIs, or service accounts, its real security posture is defined by the permissions those components confer. That means identity lifecycle, authorisation scope, and runtime observability are now part of AI governance. The practitioner conclusion is straightforward: if the agent can act, then its identity must be managed like any other high-risk workload identity.
Visibility without runtime control is not enough. The article correctly separates visibility, governance, and runtime protection, and that separation should shape how the market talks about agentic security. Inventory and policy help, but they do not stop an unsafe action in flight. Teams should assume that static governance alone will miss the moment where an agent crosses from intention into impact.
The market is converging on action-layer security for AI systems. Prompt filters, LLM gateways, and basic DLP address only the surface of the problem. The next control plane is the one that understands tool permissions, live authorisation, and business-effecting actions. For security leaders, that means evaluating whether their AI governance model covers the execution layer or still stops at the conversation layer.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Execution-path security is the governance gap most teams have not yet closed. The practical problem is no longer whether the model can be manipulated into unsafe text, but whether the agent can be authorised into unsafe action. That shift means agentic programmes need control over tool execution, API scope, and runtime enforcement, not just prompt hygiene.
Agent identities are becoming production identities. Once an agent can trigger refunds, update records, or touch internal systems, its access pattern belongs in the same governance conversation as service accounts and privileged workloads. The operational question is whether teams can prove what the agent was allowed to do at the moment it acted.
AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That scale makes it harder to trust static assumptions about agent access, because the control problem now includes the credentials, tools, and connectors around the model.
For practitioners
- Define an execution-path control model Map every prompt-to-tool-to-API-to-data chain and identify where the agent can change state, not just where it can generate text.
- Inventory delegated agent identities List the service accounts, tokens, MCP servers, and API credentials each agent can use, then classify them by business impact and privilege scope.
- Add runtime approval boundaries Require live enforcement points for high-risk actions such as refunds, data export, configuration changes, and ticket updates.
- Correlate build, config, and runtime telemetry Tie code findings, enabled tool settings, and observed agent actions into one review workflow so mismatches are visible quickly.
- Separate conversational safety from action safety Keep prompt and output controls, but do not treat them as substitutes for authorisation at the tool and API layers.
Key takeaways
- Agentic AI expands the security boundary from what a model says to what an integrated system can do with tools, APIs, and delegated access.
- The most important control question is no longer prompt safety alone, but whether the agent’s execution path is authorised, observable, and limited to its task.
- For identity and security teams, agent identities, tool permissions, and runtime enforcement now need joint governance because the business impact happens at the action layer.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article is about agents acting through delegated tools and APIs with excessive authority. |
| ASI02 — Tool Misuse | The core risk is unsafe use of tools, APIs, and workflow actions by an agent. | |
| Recommendation — Constrain agent privileges and require explicit authorisation for every state-changing tool call. Restrict tool access to the minimum action set needed and monitor all tool invocations. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent identities and service accounts become overprivileged when they can reach business systems broadly. |
| Recommendation — Audit agent and service-account scopes and remove any permissions not required for the intended task. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is directly implicated when agents can issue refunds, update records, or change configurations. |
| Recommendation — Apply least privilege to agent credentials and separate read, write, and execute permissions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Weakly governed agent pathways can be abused to move from tool access into broader system access. |
| Recommendation — Map agent abuse paths to TA0006 and TA0008 so detection focuses on tool-to-system progression. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on whether AI agents are authorised for the actions they can perform. |
| Recommendation — Review agent entitlements against PR.AA-05 and revoke any capability not tied to a defined business need. | ||
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.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to govern delegated access with confidence. It helps identity and security teams connect authorisation, lifecycle control, and runtime oversight across modern AI and workload environments.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org