TL;DR: The core security problem is not escape from runtime but preventing an agent from turning technically valid requests into unauthorised business action, according to Jamf. Jamf argues that agentic security must move beyond containment of code execution to constraining enterprise authority, with distinct identities, scoped credentials, governed MCP servers and deterministic authorization outside the model.
At a glance
What this is: Jamf’s analysis says agentic security fails if teams only contain execution, because agents can still use legitimate APIs, tools and credentials to change enterprise systems.
Why it matters: IAM, PAM and NHI teams need to govern agent identity, tool scope and downstream authorization together, because runtime isolation alone does not prevent misuse of valid authority.
Context
Agentic security breaks when teams assume that isolating a model from its host also contains what it can do. In practice, an agent can still operate through legitimate APIs, private databases and cloud interfaces if its identity and authorisation are too broad.
The governance gap is that enterprise programmes often treat execution control and authority control as the same thing. For agentic systems, they are separate layers, and the authority layer must be constrained first. See AI agent authorisation as the foundation for that distinction.
Key questions
Q: How should security teams govern agentic systems that access sensitive data?
A: Start with declared policy for what data is sensitive, which identities may access it, and what conditions make the access acceptable. Then compare real activity against those rules continuously. In agentic environments, governance fails when teams rely only on role assignment or approval history, because runtime behaviour can change the risk materially.
Q: Why do agentic systems require a separate authorization layer?
A: Because a model cannot safely enforce its own permission boundary. Context can be poisoned, tool output can be misleading and the same request may be valid in one session and dangerous in another. A separate authorization layer evaluates the exact operation, target and parameters before anything reaches a live system.
Q: What do security teams get wrong about MCP and tool governance?
A: They often review each integration in isolation and miss the combined permission path. Two legitimate tools can create a new capability that neither one should have alone. Governance has to assess the full chain of action, because risk emerges from composition as much as from individual access rights.
Q: What happens when an agent uses broad credentials for narrow tasks?
A: The agent can still act correctly but remain dangerously overpowered. A valid token with excessive resource scope or operation scope lets one approved task expand into unrelated reads, writes or deletions. That is why time limits alone are not enough and task scope has to be enforced as well.
Technical breakdown
Why separate agent identity from the launching system?
An agent should not inherit the credentials of the app, workstation, CI pipeline or service account that starts it. A separate identity creates attribution, revocation and policy boundaries that can be audited independently. When the agent acts on behalf of a user, delegated user context can preserve existing access rules without creating a shared super-identity. Short-lived credentials help, but scope still has to be constrained by time, resource and operation, otherwise a valid token can still become a broad privilege grant. See the Agentic AI Identity Guide.
Practical implication: Treat every agent as its own governed identity, not as an extension of the launcher.
How should teams govern MCP servers and tools?
MCP servers are not passive connectors. They can expose filesystem access, databases, SaaS tools, browser automation and command execution, which means they expand the trusted computing base of the agent system. Tool governance therefore has to cover approval, ownership, versioning, token audience validation and downstream access. Narrow tools matter because generic interfaces let an agent compose actions that were never intended to be available together. See the MCP Security Guide.
Practical implication: Approve MCP servers as privileged integrations and restrict tools to parameterised, purpose-built operations.
Why must authorization sit outside the model?
A model can propose an action, but it cannot safely decide its own permission boundary because the prompt, context or tool output may be compromised. Deterministic policy enforcement must evaluate the authenticated identity, the initiating user, the resource, the parameter set and the current risk before allowing the request. That keeps authorisation tied to the exact operation, not just the tool name. In agentic systems, complete mediation is the control that prevents one approval from becoming blanket access. See the Authorisation Models Guide.
Practical implication: Enforce allow or deny decisions in a policy layer outside the agent runtime.
Breaches seen in the wild
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authority, not runtime isolation, is the real control plane: This article correctly separates containment of code execution from containment of enterprise action. An agent can be fully sandboxed and still create material risk if its identity, tools and downstream permissions are not constrained. The practitioner lesson is that agent security starts with what the enterprise will let the agent accomplish, not with where the code runs.
Task-scoped identity is the minimum viable governance model: Reusing the launcher’s credentials or a generic service account collapses attribution, revocation and least privilege into a single ambiguous trust bucket. That model was built for stable workloads, not for systems that initiate actions dynamically. The implication is that agent identities have to be individually governed and independently removable.
MCP changes the trust boundary because it carries authority, not just data: A server that exposes local files, databases or cloud APIs becomes part of the trusted computing base the moment it is connected. That means approval, ownership, tool definition integrity and token audience validation are governance requirements, not deployment hygiene. MCP security guidance matters because the interface itself can expand enterprise authority.
Deterministic policy enforcement is the only defensible authorisation pattern: The model can suggest actions, but policy has to decide them outside the model because prompts, context and tool outputs are mutable and potentially poisoned. This is the same structural lesson that applies across human, workload and agentic identity, but it becomes sharper when the decision-maker is probabilistic. The practical conclusion is that permission decisions must remain externally enforced.
From our research library:
- Only about one-third of approximately 500 organizations surveyed by McKinsey in 2026 report maturity level three or higher across agentic AI governance controls.
- Read next: AI Agent Authorisation Guide
What this signals
Identity governance for agents will shift from who can log in to what each session is allowed to do: the programme boundary moves from authentication to per-action authorisation, and that makes policy mediation the central control rather than a supporting one. Teams that still think in terms of a shared service account model will miss the governance failure introduced by delegated authority.
Task-scoped authority becomes the new baseline for agent programmes: once an agent can query databases, invoke APIs or modify cloud resources, long-lived privilege stops being a tolerable default. The operational question is no longer whether an agent is authenticated, but whether the specific task, resource and action set are bounded tightly enough to survive abuse.
Approved tool registries will matter as much as identity registries: if tools can be added, renamed or redefined without governance, the control plane is already compromised at the interface layer. This is why agentic AI security work has to include tool ownership, schema integrity and downstream authorisation, not just model safety.
For practitioners
- Define a unique agent identity per workflow Stop letting an agent inherit the launcher’s credentials. Use a separate, auditable identity that can be revoked without affecting the user, workstation or CI system that initiated the task.
- Broker secrets outside the agent runtime Keep long-lived secrets in a host-side proxy, broker or gateway and attach them only after the request has passed policy checks. Restrict issued credentials by time, resource and permitted operations.
- Approve MCP servers as privileged integrations Maintain an approved registry, assign an owner for every server, review tool definitions and record which agents may connect. Treat changes in tool scope or schema as governance events.
- Move allow or deny decisions into policy Use a deterministic policy layer to evaluate the authenticated identity, initiating user, resource and parameters before an action is accepted. Do not let the model decide its own permission boundary.
- Stage destructive actions before execution Require drafts, plans, pull requests or pending updates for anything production-facing, irreversible or externally visible. Add human approval or step-up authentication before the staged output can become a live change.
Key takeaways
- Agentic security fails when teams focus only on containing execution and ignore the authority the agent can still exercise through valid tools and credentials.
- The article’s central control shift is from runtime isolation to scoped identity, governed MCP access and deterministic authorization outside the model.
- Practitioners need to treat agent identity, tool governance and action safety as one control stack, because any weak layer can turn a legitimate request into enterprise impact.
Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Authorisation Models Guide · Agentic AI Security Guide · MCP Security Guide
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 centres on agent identity, scoped authority and misuse of delegated privileges. |
| Recommendation — Apply ASI03 by binding each agent to explicit task scope, resource scope and revocation paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The piece warns against inherited credentials and overly broad token use for agents and MCP servers. |
| NHI-05 — Overprivileged NHI | A central theme is that valid credentials can still be too powerful for the task being executed. | |
| Recommendation — Use NHI-04 to issue separate identities and validate credentials before any agent action is authorised. Apply NHI-05 by shrinking agent permissions to the exact resources and operations required. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article’s risk model includes credential misuse and movement across cloud, SaaS and internal services. |
| Recommendation — Map agent abuse paths to TA0006 and TA0008 so over-scoped credentials are detected as attack enablers. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Short-lived credentials, revocation and token handling are core to the article’s control model. |
| Recommendation — Use IA-5 to govern credential issuance, scope, rotation and revocation for agents and tool brokers. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on enforcing permissions and entitlements outside the model. |
| Recommendation — Implement PR.AA-05 so every agent action is checked against explicit entitlements before execution. | ||
Key terms
- 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.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Deterministic Authorization: Deterministic authorization means the same request, policy, and context always produce the same decision. That property matters because security teams need access controls they can reproduce during audits, investigations, and incident response. It is especially important when AI is involved upstream but not at the decision boundary.
- Task-Scoped Credential: A task-scoped credential is a secret or token limited to one specific job, workflow, or short time window. It reduces the chance that an AI agent or automation process can reuse access outside its intended purpose, which is essential when the system can operate continuously or autonomously.
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 building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org