The Agentic Trust Framework: Zero Trust governance for AI agents

Autonomous AI agents can access applications, APIs, data, tools, and other agents without continuous human direction. The Agentic Trust Framework (ATF) extends Zero Trust principles to this new operating model by requiring organizations to continuously verify identity, behavior, data access, boundaries, and recovery rather than trusting an agent simply because it authenticated successfully.

The goal is to make autonomy bounded, observable, testable, and recoverable.

Agentic Trust Framework – essentials

• AI agents create new trust decisions because they can independently reason, select tools, generate actions, preserve context, and interact with multiple systems while pursuing a goal.
• Zero Trust still applies, but authentication alone isn’t enough. Agent actions, permissions, behavior, and context also need continuous verification.
• The Agentic Trust Framework provides a governance model for progressively granting autonomy based on demonstrated trustworthiness.
• ATF organizes agent governance around five elements: Identity, Behavior, Data Governance, Segmentation, and Incident Response.
• Governance and security testing solve different problems. Governance determines what an agent should be allowed to do. Security testing determines whether the systems and controls around that agent withstand adversarial activity.
• A well-governed agent can still interact with a vulnerable application or API. Conventional application security remains essential.
• Autonomous security systems also need verification. Agentic security testing should validate security conclusions rather than treating AI-generated findings as inherently trustworthy.

The Agentic Trust Framework is an open governance specification for applying Zero Trust principles to autonomous AI agents. Instead of assuming an agent remains trustworthy after authentication, ATF continuously evaluates who the agent is, what it is doing, what data it consumes and produces, where it can go, and what happens if it behaves unexpectedly. The ATF was published through the Cloud Security Alliance (CSA).

Why AI agents create a new Zero Trust problem

Traditional software generally follows logic that developers explicitly define. Give a conventional service access to an API, for example, and its developers have normally specified which endpoints it calls, which parameters it supplies, and how it processes the response.

AI agents introduce another layer of decision-making. Depending on their design, they may interpret a goal, plan a sequence of actions, select tools, generate parameters, retrieve information, retain context, delegate tasks, and adapt their next action based on previous results. That makes authorization more complicated – giving an agent permission to use a tool is not necessarily the same as authorizing every action the agent might decide to perform with that tool.

Consider an enterprise agent with access to a customer relationship management API. A conventional integration might make a fixed set of API calls. An autonomous agent could dynamically decide which records to retrieve, how much data it needs, which other systems to combine that information with, and what action to take next. Each decision potentially changes the security context.

The Agentic Trust Framework was developed specifically for this governance problem. ATF applies the established Zero Trust idea of minimizing implicit trust to agents whose behavior can be dynamic and probabilistic. Rather than treating trust as a one-time access decision, the framework makes it something an agent must continually demonstrate.

This concern is broader than any single framework. The National Institute of Standards and Technology (NIST) launched its AI Agent Standards Initiative in February 2026 and has separately explored how established identity and authorization standards can apply to software and AI agents that access data, tools, and applications.

What does Zero Trust mean for AI agents?

Zero Trust for AI agents means minimizing implicit trust and continuously verifying agent identity, permissions, actions, data access, and context. Agents should receive only the permissions they need, operate inside technically enforceable boundaries, and gain greater autonomy only when appropriate controls and monitoring demonstrate that the risk is acceptable.

The familiar Zero Trust principles remain relevant:

• Verify explicitly
• Apply least privilege
• Assume breach
• Minimize implicit trust
• Continuously evaluate access

Agentic systems add new dimensions because any access can lead to autonomous action. Security teams may need to make authorization decisions around individual actions, dynamically selected tools, persistent context, delegation to other agents, and changing operational conditions.

The more consequential an agent’s actions can be, the more important it becomes to distinguish between instructions intended to influence the model and controls capable of enforcing a boundary.

AI guardrails vs. security controls

AI guardrails and enforceable security controls can work together, but they perform different jobs. A guardrail attempts to shape what an agent should do. An enforceable security control determines what the agent can do regardless of what the model decides. That distinction becomes critical when agents have access to sensitive data or high-impact tools.

Guardrails still have value – they can guide expected behavior, reduce undesirable outputs, and establish operational rules for an agent. But a prompt that says “never delete production data” is not equivalent to an authorization policy that actually makes deletion impossible.

For security-critical boundaries, organizations should favor controls that remain effective even when an agent misunderstands instructions, behaves unexpectedly, or encounters adversarial input.

The five core trust questions for AI agents

CSA’s Agentic Trust Framework organizes agent governance around five questions. Together, they provide a practical way to examine an agent’s trust requirements:

Identity: Who are you?

An enterprise needs to know which agent is acting, who owns it, why it exists, and which capabilities and permissions belong to it. This becomes especially important as agent populations grow. Reusing human accounts or sharing credentials across agents makes attribution and least-privilege enforcement much harder.

Agent identity also needs to survive multi-agent workflows. If an action passes through a coordinator and several agents before reaching a tool, organizations still need to establish who initiated it and under whose authority it was performed.

Behavior: What are you doing?

Authentication establishes identity at a point in time, but it doesn’t establish that every subsequent action is legitimate. Agent behavior therefore needs to be observable and attributable. Logs should make it possible to connect actions with an agent identity and session context, while monitoring can identify unexpected deviations from established patterns.

For higher-risk systems, knowing that an agent called an API may not be enough. Security teams may also need the context surrounding that action, including the tool selected, the information used, and the sequence of events that led to it.

Data governance: What are you eating? What are you serving?

Agents both consume and generate information. Either direction can create security risk. Untrusted inputs can manipulate agent behavior through attacks such as prompt injection or poisoned data. Outputs can expose sensitive information or trigger downstream actions in other systems. Data governance therefore needs to cover inputs, outputs, provenance, sensitive-data handling, and the boundaries between trusted and untrusted sources.

Segmentation: Where can you go?

Least privilege for an agent needs to limit more than the applications it can reach. Where possible, controls should also restrict resources, operations, tools, data, and duration of access.

This is where action-level authorization becomes especially important. An agent might legitimately need read access to customer records without needing permission to export them, change account details, or delete them. The more autonomous the agent, the more consequential those distinctions become.

Incident response: What if you go rogue?

Assuming breach means designing for failure before it happens. Agentic incident response needs mechanisms for rapidly containing unexpected activity, revoking credentials, interrupting workflows, and reducing or removing autonomy. CSA specifically includes circuit breakers, kill switches, and containment in this element of ATF.

The objective isn’t merely to detect a problem. It is to stop an autonomous system from continuing harmful actions while teams investigate and recover.

Multi-agent systems multiply trust decisions

A single agent already creates multiple trust relationships. A multi-agent architecture creates many more, as in this simplified but already complex example:

Every connection creates another question about identity, authority, context, and delegation.

If Agent A instructs Agent B to perform an action, for example, what proves Agent A was authorized to request it? What permissions should Agent B inherit from Agent A, if any? Can it distinguish a legitimate delegation from a compromised agent attempting to expand its access?

Multi-agent environments therefore need explicit agent identities, scoped permissions, authenticated communications, controlled delegation, limited context sharing, provenance, and monitoring.

This is one reason agentic Zero Trust cannot stop at the initial authentication boundary. Trust relationships can change as work passes between agents and tools.

How much autonomy should an AI agent receive?

ATF treats autonomy as something agents earn rather than receive permanently at deployment. Its maturity model progresses from Intern through Junior and Senior to Principal, with increasing autonomy accompanied by increasingly stringent governance requirements. Promotion requires passing gates covering performance, security validation, business value, incident record, and governance sign-off. The framework treats incidents as grounds for demotion, particularly at the highest autonomy level.

The underlying principle is more useful than any individual label: greater autonomy should require stronger evidence that the system can operate safely within its boundaries.

A practical enterprise progression might look like this (note that this differs slightly from ATF’s own four-level model but reflects the same principles):

The appropriate level depends on consequences, not merely technical capability. An agent that summarizes public documents poses a different risk from one that can transfer funds, modify production systems, or access sensitive customer data.

Autonomy should be an earned capability, not the deployment default.

Governance is not the same as security testing

Strong agent governance doesn’t guarantee that the applications an agent uses are secure. Imagine an agent that is legitimately authorized to access an API endpoint like:

GET /api/accounts/{account_id}

The agent’s identity is valid, its permissions are correctly scoped, and its behavior is expected.

But now suppose the API contains a broken object level authorization (BOLA) vulnerability. If the same agent changes /accounts/1234 to /accounts/5678 and gets unauthorized access to a different customer’s account data, you could have a data breach. In this case, the agent governance layer did what it was supposed to do – but the application security layer failed.

It’s crucial to remember that AI agents still operate through ordinary software systems. They authenticate to applications, call APIs, invoke services, process data, and use business logic. Those systems can contain the same vulnerabilities they contained before anyone connected an AI agent to them.

The Agentic Trust Framework describes agent governance, while application security testing validates the applications and APIs the agent relies on. Enterprises need both.

A seven-layer model for enterprise agent trust and security validation

The five ATF elements provide a strong foundation for governing autonomous agents. For enterprise security programs, it is also useful to view those governance requirements together with the independent security validation needed around the agent.

Note that the following seven-layer model is how Invicti views that combined problem. It is not part of the CSA Agentic Trust Framework and should not be interpreted as an alternative version of ATF.

Layer 1 – Identity

Establish a unique identity for every agent and define its owner, purpose, authentication method, and lifecycle. An agent that cannot be uniquely identified cannot be reliably governed, monitored, or held accountable.

Layer 2 – Authorization

Define what each agent is permitted to do. Authorization should cover applications, APIs, tools, operations, data, and delegation rather than relying on broad access at the system level. High-risk actions may require additional authorization or human approval.

Layer 3 – Behavioral governance

Establish what normal behavior looks like and maintain enough visibility to detect meaningful deviations. Logging and attribution should allow teams to reconstruct important actions, while monitoring can identify unusual tool usage, access patterns, or changes in behavior.

Layer 4 – Data governance

Control what information an agent can consume, retain, combine, and expose. This includes sensitive-data access, untrusted input, provenance, memory and context, generated output, and data exchanged between agents.

Layer 5 – Segmentation and execution boundaries

Limit where an agent can operate and what it can reach. Network boundaries, scoped credentials, tool permissions, API authorization, and workload isolation can all reduce the blast radius of an agent that is compromised or behaves unexpectedly.

Layer 6 – Incident response and recovery

Prepare to contain agents and reduce autonomy when trust assumptions fail. Teams need mechanisms to interrupt actions, revoke credentials, disable tools, isolate affected systems, preserve evidence, and restore safe operation.

Layer 7 – Security validation

Independently test whether the applications, APIs, permissions, and security boundaries surrounding the agent actually withstand attack.

This final layer is deliberately separate from governance. A policy can be correctly designed but incorrectly implemented. An agent can have appropriate permissions but use an API with an exploitable authorization flaw. A valid segmentation rule can exist while another attack path bypasses it. Security validation provides the adversarial check.

The seven layers create a practical progression:

• Identity establishes who the agent is.
• Authorization defines what it may do. 
• Behavioral governance establishes how it should behave.
• Data governance establishes what it can consume and produce.
• Segmentation constrains where it can act. 
• Incident response prepares for failure. 
• Security validation tests whether those assumptions survive contact with an attacker.

Why agentic systems increase the importance of application security testing

Agents don’t make conventional vulnerabilities disappear – and in some environments, greater autonomy can increase the consequences of those vulnerabilities being exploited.

An agent might have legitimate access to authenticated applications, APIs, administrative interfaces, internal services, databases, or development systems. Those surfaces can still contain BOLA, broken access control, SQL injection, command injection, server-side request forgery (SSRF), authentication weaknesses, business-logic flaws, and exposed sensitive data. On top of that, an autonomous system can also interact with more of that environment than a typical user during a single task.

This creates two distinct security requirements. First, organizations need agent-specific testing for risks such as prompt injection, tool misuse, insecure inter-agent communication, memory poisoning, and excessive agency. The OWASP Top 10 for Agentic Applications for 2026 provides dedicated guidance for this emerging class of threats.

Second, they still need application security testing for the applications and APIs underneath the agentic layer. This is especially important for APIs because they are a natural interface between autonomous software and enterprise systems. Authentication and authorization testing, runtime vulnerability testing, business-logic assessment, and API discovery remain relevant whether an endpoint is being called by a browser, conventional software, or an AI agent.

How Invicti Agentic Pentest can help validate agent-connected applications

Agentic pentesting provides one way to apply adaptive offensive testing to applications and APIs that autonomous agents depend on. It should not be confused with an AI-agent governance system. Invicti Agentic Pentest does not establish agent identities, assign enterprise permissions, govern Model Context Protocol (MCP) access, or enforce runtime policies for an organization’s AI agents. Its role is security testing.

Invicti Agentic Pentest combines AI-driven offensive reasoning with Invicti’s established dynamic application security testing (DAST) capabilities. Its workflow moves through reconnaissance, attack, and confirmation and reporting:

• During reconnaissance, agents use information from multiple sources, including the established crawler, application technologies, authentication context, and (when available) source code, to develop a testing strategy specific to the application.
• During attack, specialized agents can work in parallel and share relevant context. This allows testing to adapt to the application and investigate promising attack paths rather than relying exclusively on a predetermined test suite. Individual attack techniques are based on Invicti’s mature suite of DAST security checks.
• Confirmation provides the crucial final step. Candidate findings are validated using Invicti’s established confirmation techniques before reporting, providing proof of exploit for confirmed vulnerabilities. This hybrid approach is intended to combine the adaptability of AI-driven offensive testing with the repeatability and runtime evidence of DAST.

It also changes the economics of penetration testing, since agentic pentesting is designed to run faster and cheaper than a manual engagement. Initial figures for Invicti’s Agentic Pentest put it at up to 10 times faster than manual testing and capped at $500 per assessment. Those economics can make it practical for organizations to test more applications more frequently rather than limiting deeper security assessments to a small portion of the portfolio.

The exact time, cost, and coverage benefits depend on the application and testing program. The more important strategic point is scalability: reducing the cost and turnaround time of an individual assessment can allow security teams to apply offensive validation across a much larger application estate.

Trust should apply to autonomous security systems too

Defensive AI shouldn’t receive implicit trust simply because it is being used for security. A defensive AI system can generate a plausible attack hypothesis and still be wrong. For a security team deciding what developers need to fix, plausibility isn’t enough. This is where Invicti’s established emphasis on proof becomes important.

AI security capabilities can reason, explore, coordinate, formulate hypotheses, and generate application-specific tests. Candidate security issues can then be checked using runtime validation rather than being reported solely because an AI system concluded that a vulnerability probably exists.

That approach reflects a broader lesson from Zero Trust: important outputs from autonomous systems should be independently verified rather than implicitly trusted. This doesn’t make Invicti Agentic Pentest an ATF implementation but rather demonstrates how a similar trust principle can be applied inside autonomous security testing itself.

How should CISOs govern AI agents?

For chief information security officers (CISOs), agentic AI turns autonomy into a governance decision. The objective has moved from simply approving or rejecting AI adoption. It is now to determine what degree of autonomy is acceptable for each use case, what evidence is required before that autonomy increases, and how quickly it can be withdrawn.

A practical CISO checklist for agent governance might be:

• Inventory AI agents and assign a business and technical owner to each one.
• Classify agents according to the potential impact of their actions and data access.
• Require unique identities instead of shared human or service credentials.
• Define explicit autonomy levels and approval gates for higher-risk actions.
• Enforce least privilege across applications, APIs, tools, data, and other agents.
• Require technically enforceable controls for critical boundaries rather than relying on model instructions alone.
• Ensure consequential agent actions are logged and attributable.
• Establish containment, credential revocation, kill-switch, and recovery procedures.
• Require security validation before granting greater autonomy and after material changes.
• Track incidents and use them as evidence when deciding whether autonomy should be maintained, increased, or reduced.

The governance question should ultimately be evidence-based: what has this agent demonstrated that justifies the level of trust the organization gives it?

What AppSec teams should do based on the ATF

Application security teams sit at the boundary between agent governance and the software those agents use. Their responsibility is not to own every aspect of AI governance but to make sure the applications, APIs, and security controls exposed to autonomous systems have been tested rather than assumed secure.

AppSec teams should:

• Identify the applications, APIs, and services that AI agents can access.
• Map authenticated and privileged attack surfaces, not only public endpoints.
• Test APIs for authorization weaknesses such as BOLA and other access-control failures.
• Continue testing for conventional application vulnerabilities, including injection, SSRF, authentication flaws, and business-logic weaknesses.
• Add agent-specific adversarial testing where agents introduce new attack paths or trust relationships.
• Validate whether security boundaries can actually prevent unauthorized actions.
• Prioritize exploitable vulnerabilities and provide developers with reproducible evidence.
• Retest fixes and material application changes rather than treating remediation tickets as proof that risk has disappeared.
• Feed validated findings into broader application security posture management (ASPM) processes so teams can prioritize and track remediation across the application estate.

AI agents change the context in which applications operate, but they don’t remove the need for systematic application security.

What developers building AI agents should do

Developers can influence agent security long before an application reaches production. Agentic systems should be designed so that security doesn’t depend on the model making the correct decision every time.

Developers building AI agents should:

• Give each agent a unique identity and avoid embedding broad, long-lived credentials.
• Scope permissions to the specific tools, APIs, operations, and data required for the task.
• Treat prompts, retrieved documents, tool responses, and other external context as potentially untrusted input.
• Separate instructions from data wherever the architecture allows.
• Validate inputs and outputs at security-sensitive boundaries.
• Put high-impact actions behind enforceable authorization and, where appropriate, human approval.
• Define explicit rules for delegation and agent-to-agent communication.
• Preserve enough logging and provenance to reconstruct important decisions and actions.
• Design interruption and recovery mechanisms before granting significant autonomy.
• Make agent-connected applications and APIs testable in development, staging, and production-appropriate environments.
• Include both agent-specific adversarial testing and conventional application security testing in the development lifecycle.

The underlying design principle is simple: assume that models, prompts, tools, and surrounding software can all fail in different ways, then build independent controls so one failure does not automatically become a security incident.

A practical approach to enterprise AI agent governance

Organizations don’t need to grant full autonomy and then work backward to establish control. A staged rollout makes it possible to connect increased autonomy with evidence that governance and security controls work.

Phase 1 – Discover

Start with inventory. Identify agents, owners, models, tools, APIs, credentials, data sources, and downstream systems. An organization cannot make meaningful trust decisions about agents it doesn’t know exist.

Phase 2 – Constrain

Establish identity, operational scope, allowed tools, least-privilege permissions, network and resource boundaries, and approval requirements. Make security-critical boundaries technically enforceable rather than relying exclusively on model instructions.

Phase 3 – Observe

Implement structured logging, provenance, behavioral monitoring, alerts, and visibility into agent actions. Ensure important actions can be attributed to an identity and reconstructed after an incident.

Phase 4 – Test

Challenge the system. Test authentication, authorization, applications, APIs, business logic, agent-specific attack paths, tool misuse, injection exposure, and attempts to bypass established controls. ATF itself recognizes security validation as a condition for increasing agent autonomy, including vulnerability assessment, penetration testing, and, at higher maturity, adversarial testing.

Phase 5 – Prove

Require evidence that important controls work. For application vulnerabilities, that can include reproducible requests, proof of exploit, remediation evidence, and retesting after a fix. For agent controls, it can mean demonstrating that unauthorized actions are actually blocked, containment mechanisms function, and incident-response procedures can revoke autonomy when necessary.

Phase 6 – Expand autonomy

Increase autonomy only when permissions are constrained, monitoring works, recovery mechanisms have been tested, and security validation provides sufficient evidence that the system can operate within its intended boundaries. And keep verifying. A change to a model, prompt, tool, API, permission, integration, or application can alter the security assumptions behind the original decision.

ATF and other AI security frameworks

The Agentic Trust Framework doesn’t exist in isolation. Organizations can use it alongside broader standards and guidance rather than treating it as a replacement.

NIST Special Publication 800-207 provides the broader Zero Trust architecture that informs the “never trust, always verify” philosophy. NIST’s AI Risk Management Framework provides a voluntary structure for managing AI risks across governance, mapping, measurement, and management, while NIST has also begun dedicated work on AI-agent identity, authorization, interoperability, and security.

The OWASP Top 10 for Agentic Applications focuses more specifically on security risks affecting autonomous, goal-driven agents. That makes it useful for identifying and mitigating attack classes while ATF addresses the governance question of how organizations maintain control as agents receive more autonomy.

ISO/IEC 42001 provides requirements for establishing and continually improving an AI management system at the organizational level, covering the responsible development and use of AI.

CSA itself also maintains the AI Controls Matrix, a vendor-neutral control framework that currently contains 247 control objectives across 18 security domains and maps to standards including ISO/IEC 42001 and ISO/IEC 27001.

These resources operate at different levels and answer different questions. ATF can help organizations structure agent-specific controls within a broader AI governance and cybersecurity program, but adopting it should not be presented as automatically establishing compliance with another framework or regulation.

Conclusion: Trust autonomous systems by verifying what they do

Agentic AI can automate a growing proportion of enterprise work. Greater autonomy, however, creates more trust decisions about identity, access, data, actions, delegation, monitoring, and recovery. The Agentic Trust Framework provides a practical structure for those decisions. It asks organizations to make trust explicit, limit autonomy according to risk, observe what agents actually do, and prepare to contain them when something goes wrong.

Agent governance covers only part of the problem – the applications and APIs those agents depend on also need to withstand attack. That is where application security validation belongs in an agentic security strategy. Invicti DAST provides runtime testing and vulnerability validation for web applications and APIs, while Invicti Agentic Pentest adds adaptive offensive testing for deeper application-specific assessment. Invicti ASPM can provide the broader visibility and prioritization layer for managing application security findings across tools and teams.

Together, these capabilities address the application security side of the equation without pretending to replace the identity, authorization, governance, and containment technologies required to implement ATF.

For organizations moving from AI experimentation to meaningful agent autonomy, the principle worth carrying forward is straightforward: grant trust deliberately, constrain it technically, and verify the systems that trust depends on.

Next steps

• Get the agentic pentesting checklist as a practical companion to this framework.
• Read about the differences between agentic pentesting, DAST and manual pentesting.
• Get a demo of Invicti Agentic Pentest to see how AI-driven offensive testing and runtime validation can help test the applications and APIs behind autonomous systems.