MITRE ATLAS and agentic AI security: what practitioners need to know

At a glance

What this is: This is an analysis of the first 2026 MITRE ATLAS update and Zenity’s contributions, with the key finding that agentic AI risk now lives in runtime orchestration, tool use, and delegated access.

Why it matters: It matters because IAM, NHI, and AI governance teams need controls that account for autonomous tool invocation, credential exposure, and delegation paths, not just model inputs and outputs.

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%).
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Zenity's analysis of MITRE ATLAS and agentic AI security

Context

MITRE ATLAS AI security is becoming a practical operating model for teams that need to understand how adversaries target agentic systems. The central governance problem is that autonomous agents do not behave like static applications or human users, so legacy IAM and application controls do not fully describe how access, tool use, and execution unfold at runtime.

In this article, Zenity’s contributions are the trigger, not the subject. The real issue for practitioners is that agentic AI collapses the boundary between identity, orchestration, and action, which makes runtime visibility and control the deciding factors in AI security.

For teams already building around AI agent governance, the useful comparison is with the broader NHI control problem. The same identity, credential, and delegation questions show up here, but they move faster and in more volatile ways because the agent decides what to do next inside the session.

Key questions

Q: How should security teams govern AI agents that use enterprise tools and APIs?

A: They should govern them as privileged non-human identities with runtime visibility, scoped access, and explicit ownership. The key is to map which tools, credentials, and data sources each agent can touch, then tie that to logging and review. If the agent can act, it must be managed like an identity, not a feature.

Q: Why do agentic browsers create risk beyond normal web automation?

A: Agentic browsers can interpret content, make decisions, and execute actions on behalf of a task, which means malicious page content can steer machine behaviour directly. That creates a control problem, not just a content problem. Teams need to assume the browser is an execution surface and restrict downloads, tool calls, and downstream actions accordingly.

Q: What breaks when AI agents can reach secrets through connected tools?

A: The trust boundary breaks because the agent’s usefulness often depends on access to tokens, keys, and service accounts held by adjacent systems. Once those tools are reachable, the agent can become a path to credential discovery or misuse. Practitioners should treat every connected tool as a potential secret source and reduce standing exposure.

Q: How can organisations tell whether their agent governance is actually working?

A: Look for complete inventory, runtime telemetry, and named owners for each agent’s access path. If you cannot answer which tools an agent used, what data it touched, and who approved the delegated access, governance is incomplete. Effective programmes can reconstruct agent actions after the fact and limit blast radius during execution.

Technical breakdown

AI service APIs as an execution layer

AI service APIs are not just integration endpoints. In agentic systems they become part of the execution path, because the agent uses them to issue commands, retrieve responses, and continue a task chain. That makes the API layer a control surface for both legitimate orchestration and adversary abuse. If an attacker can blend malicious activity into normal agent traffic, traditional perimeter monitoring sees only approved service calls. MITRE ATLAS usefully captures this by treating the API itself as part of the attack path, not just a passive dependency.

Practical implication: monitor API activity as identity behaviour, not only as traffic, and tie every agent API call to a governed workload or agent identity.

AI agent tool credential harvesting and data access

Agent tool credential harvesting describes the way attackers can abuse an agent’s connected tools to retrieve secrets, tokens, and API keys stored in adjacent systems. The risk is structural: agents are often given broad tool access so they can complete work without human intervention, which means the tools themselves may expose more than the original model ever should. Once an attacker reaches the tool boundary, the agent can become a shortcut into adjacent identities and services.

Practical implication: inventory which tools expose secrets or privileged tokens to agents and remove any implicit trust between the agent and downstream services.

Agentic browsers, clickbait, and runtime manipulation

Agentic browsers create a distinct attack path because they interpret pages and documents on behalf of a task, not a person. That means hidden instructions, malicious metadata, or prompt-shaped content can steer the agent into downloading files, invoking tools, or executing workflows that look task-aligned. This is not human phishing with a machine in the middle. It is a control problem where the attacker targets the agent’s interpretation layer and the runtime decision loop at the same time.

Practical implication: restrict what agentic browsers can download, execute, or pass to downstream tools, and treat untrusted content as an execution trigger.

Threat narrative

Attacker objective: The attacker wants to hijack agentic execution so the agent itself becomes a covert path to credentials, control, and downstream enterprise access.

1. Entry occurs when an adversary targets a connected AI service API, a tool interface, or a web page designed for agent consumption, allowing malicious content or commands into the agentic environment.
2. Credential access follows when the agent’s connected tools or delegated services expose tokens, secrets, or API keys that can be harvested through normal-looking workflow activity.
3. Escalation occurs when the attacker uses the agent’s own orchestration logic, browser actions, or tool invocation path to continue execution without obvious human review.
4. Impact lands as covert command and control, unauthorized data access, or destructive workflow execution across the enterprise systems the agent can reach.

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 governance is now an identity problem, not a model problem. The article’s strongest signal is that MITRE ATLAS is expanding to cover the places where agents act, not just the places where they reason. That is the right shift for the field because the security failure now sits in runtime access, tool invocation, and delegated authority. Practitioners should treat agentic AI as part of identity governance, not a separate AI-only domain.

Runtime visibility is becoming the new control plane for agentic systems. If you cannot see which tools, credentials, and data an agent touched during execution, you cannot reconstruct the attack path after abuse. That makes ATLAS useful not just as a threat catalog but as a way to map monitoring, identity, and incident response around real agent behaviour. The practitioner conclusion is straightforward: if runtime activity is opaque, governance is already behind.

Agentic security collapses the old assumption that identity is passive after issuance. Identity review was designed for access that persists long enough to be observed, certified, and revoked. That assumption fails when an agent can select tools, invoke services, and chain actions inside a single task window. The implication is that teams must rethink how they define observable privilege for autonomous actors.

Agentic AI security will converge with NHI, SaaS, and API governance. The article reflects a market where the hard boundary between AI security and identity security is disappearing. Once agents can touch APIs, browse, authenticate, and move through enterprise workflows, the relevant control stack spans workload identity, zero trust, and policy enforcement. Practitioners should stop managing these as separate programmes and start treating them as one attack surface.

AI agent tool credential harvesting is the named concept teams should track. The article makes clear that the most dangerous abuse path is not the model output itself but the adjacent tools that expose secrets to make the agent useful. That failure mode matters because it turns delegated utility into credential leakage. The practitioner conclusion is to reassess every tool that an agent can reach as a potential secret source, not just a productivity dependency.

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.
• 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.
• The governance response needs to extend beyond access policy into identity observability, which is why The 52 NHI breaches Report remains relevant for teams mapping real abuse patterns.

What this signals

AI agent governance is converging with NHI governance faster than most programmes are structured to handle. With 48% of organisations still blind to what their AI agents access, the gap is no longer about awareness but about operational control. Teams need one programme that can track workload identities, delegated tools, and runtime behaviour across the same control plane.

Agentic attack paths will force identity teams to widen their detection model. The practical issue is not just whether an agent is authorised, but whether its action chain can be reconstructed after the fact. That is why runtime telemetry, tool-level logging, and identity attribution need to be designed together rather than bolted on later.

MITRE ATLAS will likely become a procurement and architecture reference point for agent security. As the category matures, vendors and defenders will increasingly be judged on whether they can map detections, governance rules, and incident workflows back to named attack techniques. Teams that align early will have a cleaner path from policy to investigation.

For practitioners

• Map agent runtime privilege chains Inventory every AI agent, the tools it can invoke, the credentials it can reach, and the downstream systems those credentials unlock. Focus on the whole runtime path, not just the model endpoint, because abuse often happens through delegated identity and service integrations. Cross-check the map against the OWASP NHI Top 10.
• Separate agent access from human workflows Stop granting broad shared access to agentic browsers and assistants that mirror human work. Issue distinct workload identities, scope them tightly, and remove any assumption that the agent should inherit the same browsing or SaaS entitlements as the user who started the task.
• Treat connected tools as credential exposure points Review every agent-connected tool for tokens, API keys, session material, or embedded secrets. If a tool can reveal credentials as part of normal operation, move it into a higher control tier and re-evaluate whether the agent should access it at all.
• Expand detection to agent-native abuse patterns Add telemetry for prompt-shaped content, hidden instructions, unusual tool invocation sequences, and unexpected API call chains. Use MITRE ATLAS mappings alongside incident response playbooks so analysts can distinguish ordinary automation from agent hijacking.

Key takeaways

• MITRE ATLAS is moving AI security away from abstract model risk and toward execution-layer abuse across tools, APIs, and agent runtime behaviour.
• The most important failure mode is not the model itself but the adjacent identities and services that let an agent reach secrets, data, and actions.
• Practitioners should treat agentic systems as governed non-human identities with runtime telemetry, scoped access, and attack-pattern mapping from day one.

Key terms

• Agentic Browser: A browser or browser-like interface that can interpret content and take actions on behalf of a task. In security terms, it is an execution surface, because it can download files, follow instructions, invoke tools, and continue workflow steps with limited human oversight.
• AI Service API: An API that lets an AI system or agent interact with services, tools, or orchestration layers. In agentic environments, it becomes part of the attack path because adversaries can hide in normal-looking service calls, reuse legitimate access, and steer execution through the integration layer.
• Tool Credential Harvesting: The abuse pattern where an attacker uses an agent’s connected tools to retrieve secrets, tokens, or API keys. It matters because the tools created to make the agent useful can also become the easiest route to adjacent privileges and broader enterprise access.
• Runtime Visibility: The ability to see what an identity, agent, or workload is doing while it is executing. For agentic systems, this includes tool calls, data access, decision chains, and downstream actions, because post-event review without runtime data leaves too much unexplained.

Deepen your knowledge

Agentic AI security and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents that act across tools and services, this is the right starting point.

This post draws on content published by Zenity: Advancing MITRE ATLAS AI Security Through Zenity’s Contributions. Read the original.