emily

From Threats to Framework: Seven Capabilities in the Agentic AI Era, Where Does Your Enterprise Stand?

By James Yang, Executive Assistant to the CEO, Profet AI

After finishing the previous article, if you are calculating which tool to buy to address each type of threat, pause for a moment. The mindset of patching vulnerabilities one by one could barely keep pace back in the era of human attackers. Now that attackers are also using AI agents, new attack techniques are emerging faster than security teams can patch them. This article is about switching to a completely different defense logic.

Zero Trust as a concept traces back to 1994, when Stephen Paul Marsh first systematically proposed it in his doctoral dissertation at the University of Stirling. NIST formally established concrete guidance with SP 800-207 in 2020. In its report “Zero Trust for AI Agents,” Anthropic applies this framework to the entirely new attack surface of agentic AI, proposing seven capability domains detailed down to an executable level.

The core logic of Zero Trust, in one sentence: trust nothing and no one, verify every access request, and assume a breach has already occurred. Expanded, this becomes three tenets:

•       Never trust, always verify: Every access request must be authenticated and authorized, regardless of whether it originates from inside the corporate network.

•       Assume breach: Systems should be designed on the assumption that intrusion will eventually happen. The focus is not on preventing intrusion, but on limiting the damage an attacker can do once inside.

•       Least privilege: Grant only the minimum access needed to complete a task, so that any single breach is contained to a small blast radius.

More important than the principles themselves is a litmus test: does this control make an attack impossible, or does it merely make the attack more inconvenient? Defenses that rely on “adding friction”, extra jump boxes, rate limiting, non-standard ports, lose most of their effectiveness against automated attackers whose cost per attempt approaches zero. Controls that actually hold up share a common trait: hardware-bound credentials, tokens that expire, cryptographic identities, and network paths that simply do not exist. This litmus test runs through all seven capability domains described below.

Article content

Anthropic breaks each capability domain into three tiers: Foundation, Enterprise, and Advanced. Enterprise builds on Foundation, and Advanced builds on Enterprise, each tier reinforcing existing controls layer by layer rather than starting over. Foundation is the entry point into Zero Trust. Enterprise is the target level most organizations of a certain size should aim for. Advanced is designed for heavily regulated industries, national security applications, or deployments where the consequences of failure are severe.

Worth noting: because of the compressed attack speed discussed in the previous article, the bar for Foundation itself has been raised. Practices once considered a reasonable starting point, such as managing risk through API key rotation, no longer qualify. Short-lived tokens, cryptographically rooted identities, identity-based isolation, and automated frontline alert triage are now baseline requirements, not advanced options.

Article content

Identity and authentication form the foundation underlying all other capabilities. Without a verifiable identity, access control cannot be enforced, and behavior cannot be attributed to a specific agent. The path runs from cryptographically rooted persistent identity, to certificate-based authentication paired with lifecycle management, and ultimately to hardware-bound identity, where credentials are stored in a hardware security module and integrity is verified through remote attestation.

Once identity is established, an agent must prove its identity again every time it accesses a service. This is service authentication. The path runs from short-lived tokens measured in minutes, to mutual TLS with certificate pinning, and ultimately to hardware-bound credentials. Managing risk through API key rotation is no longer sufficient, because credentials that can be extracted from a codebase do not become meaningfully harder to steal no matter how often they are rotated.

An agent with legitimate permissions has a genuine identity. The problem is what it does once authorized. The path runs from role-based access control with default deny, to attribute-based access control that factors in context such as time, location, and risk score, and ultimately to real-time authorization that is re-evaluated for every single action. OWASP’s concept of Least Agency extends least privilege to cover what each tool is allowed to do, how often, and where, for example limiting a database tool to read-only queries.

It is worth being precise about the difference between RBAC and ABAC. RBAC (role-based access control) only looks at what role an agent holds. Once a role is assigned, its scope of permissions is fixed, and every agent under that role has identical access regardless of context. ABAC (attribute-based access control) goes further and factors in the context of the request itself, such as time, location, data sensitivity, and risk score. Two agents may both be customer service agents, but one querying general customer data during normal hours will be allowed through, while the same agent pulling large volumes of highly sensitive data late at night may be denied or asked for additional verification. Moving from RBAC to ABAC is essentially upgrading from a static judgment of “who you are” to a dynamic judgment of “what you are doing right now and how risky it is.” This is the single most important upgrade in moving from Foundation to Enterprise.

While the permission model decides whether access should be granted at all, the scope of that access determines when and for how long it can be exercised. Static permissions, once granted, persist indefinitely, remaining active even after the task is finished and creating long-term exposure. Dynamic permissions are elevated only for the duration of task execution and are withdrawn immediately afterward. The strictest form, just-in-time and just-enough access (JIT/JEA), compresses even the act of elevation to nearly the moment of use, granting access only at the instant it is actually needed and automatically revoking it on timeout or task completion, leaving no residual access behind. Last is the boundary of resources: identity-based isolation as the primary control, supplemented by network segmentation, progressing to containerized sandboxing, and ultimately to hardware isolation. For agents that process untrusted input, sandboxed execution is standard practice, not optional.

Access control determines what gets blocked. Observability determines what actually happened. Logging progresses from complete records with timestamps, to tamper-evident audit trails, and ultimately to real-time streaming into a centralized monitoring platform. But before chasing the specifications of all three tiers, it is worth first establishing measurement for two metrics: dwell time (the interval between an anomaly occurring and a human noticing it) and coverage (the proportion of alerts that are actually investigated). These are the two metrics where AI automation delivers the greatest leverage.

Traceability is a separate dimension: generating a unique identifier for each request that follows it through every subsequent action, progressing to distributed tracing across multi-agent workflows, and ultimately to a complete provenance chain that supports replaying the full decision history. Logging answers “what happened.” Traceability answers “why it happened.”

Behavioral monitoring has to judge whether a given behavior is normal or suspicious, which requires an established baseline before anomalies can be identified. Baselines progress from being manually defined, to automatically learned statistical baselines, and ultimately to baselines that continuously update and can detect slow, gradual drift. This tier specifically addresses techniques such as long-term memory drift. Anomaly detection progresses from threshold-based alerts, to statistical methods, and ultimately to machine learning models that incorporate contextual information.

Once an anomaly is detected, response speed is what actually determines the extent of the damage. The division of labor is clear: automation handles the paperwork, logging, evidence collection, and drafting initial reports, while decisions about containment, disclosure, and customer communication remain with humans. Response capability itself also progresses through three tiers: alerts routed to the security team with a triage agent producing an initial assessment, progressing to automated execution of containment actions, and ultimately to agentic SOAR capable of coordinating containment across multiple systems. What automation should do is free up human response time, not replace final judgment.

This domain is the direct countermeasure to indirect prompt injection. On the input side, the path runs from basic format validation, to content filtering that screens out encoded payloads and suspicious instructions, and ultimately to multi-layer validation combining AI classifiers with content boundary markers. SQL injection has well-defined attack patterns that can be defended against, but agent input is free-form and unpredictable, so rule-based defense alone is not enough.

The output side guards against data exfiltration: progressing from scanning for sensitive patterns, to analyzing the semantics of output to identify social engineering risk, and ultimately to requiring human approval for high-risk actions. Input validation prevents malicious manipulation. Output control prevents data leakage. Both are essential.

When every other defense fails and a breach actually occurs, attackers often turn to tampering with the agent’s own configuration. The path runs from version control, to cryptographic signing, and ultimately to immutable infrastructure, where configurations are never modified but wholesale replaced, with image integrity verified before execution.

One practice runs counter to intuition: for components where risk is acceptable, enabling automatic updates is actually safer than insisting on manual approval, because the delay inherent in manual approval is itself a risk. The solution is to let automatic updates coexist with pre-deployment signature verification: signed updates flow through automatically, while unsigned changes are rejected outright. Recovery follows a similar path, from documented rollback procedures, to automated rollback, and ultimately to self-healing systems. No amount of automation can save a situation that cannot reliably roll back to a known good state.

Technical controls can only enforce what governance policy defines. The path runs from a documented acceptable use policy, to a cross-functional governance framework that includes security, legal, and business stakeholders, and ultimately to embedding policy checks into the deployment pipeline itself, automatically detecting violations. Shadow AI, meaning employees using LLM tools on their own without approval, bypasses every one of the controls described above. This is the reality governance has to confront.

Having gone through the seven capability domains, you do not need to redesign your defenses for every new attack technique that emerges. What you need to do is check where your enterprise’s existing agent deployments stand across these seven areas. Identity makes attribution and access control possible. Observability reveals what actually happened. Behavioral monitoring detects anomalies. Input and output controls intercept attacks at the boundary. Integrity makes recovery possible. Skip any one of these areas, and that is the gap attackers will come through.

The next article moves from framework to implementation: a concrete operational workflow, and how defense teams can accelerate their security operations to keep pace now that attack speed has compressed to a matter of hours.

From Threats to Framework: Seven Capabilities in the Agentic AI Era, Where Does Your Enterprise Stand? Read More »

When Attackers Also Wield AI Agents, the Ground Beneath Enterprise Defense Starts to Shift

By James Yang, Executive Assistant to the CEO, Profet AI

AI is destabilizing the balance of speed between attackers and defenders, and most enterprises have yet to grasp this. Palo Alto Networks Unit 42’s 2026 Global Incident Response Report, drawing on more than 750 major security incidents across over 50 countries, found that the fastest 25% of attacks now take an average of just 72 minutes from initial access to full data exfiltration, four times faster than the previous year. The same report found that attackers begin automated scanning an average of 15 minutes after a vulnerability is disclosed.

This velocity is not an isolated finding. Verizon’s 2026 Data Breach Investigations Report found that nearly one third of data breaches now originate from software vulnerabilities, surpassing stolen credentials as the leading initial access vector. On the defense side, the World Economic Forum and KPMG’s Empowering Defenders report offers a telling counterpoint: organizations with mature AI defense capabilities cut breach detection and response cycles by roughly 80 days and reduce average breach costs by up to 1.9 million US dollars.

Seventy two minutes. Fifteen minutes. This is the attacker’s timetable today. Can your security team keep pace?

Enterprises are deploying AI agents at an equally striking pace. BCG’s 2026 AI Radar found that 90% of CEOs worldwide expect AI agents to deliver measurable ROI this year. Gartner forecasts that by the end of 2026, 40% of enterprise applications will incorporate task specific AI agents, up from under 5% in early 2025.

Taken together, these numbers point to the same conclusion: AI does not take sides. It accelerates both defenders and attackers at once. The only question is who recognizes that the rules have changed first.

Conversations about AI security and governance have traditionally centered on the model itself: Is it safe? Will our data be used for training? What does the privacy policy say? These are valid questions, but they belong to the old battlefield. What deserves real attention in 2026 is something else entirely: as enterprises push AI agents to the front lines, attackers are arming themselves with the same technology, often well ahead of the enterprises they target. Governance itself has quietly become a competitive advantage.

Article content

Traditional security logic is sound: verify identity, confirm authorization, allow actions within scope. That logic has protected enterprises for two decades. But an AI agent operating with legitimate, properly issued credentials has not broken through any door it was not supposed to open. The problem lies in what it does once it has been authorized.

This is the most fundamental way AI agents differ from every prior category of security incident. Traditional access control governs who gets through the door, but an agent capable of reading databases, sending emails, and querying industrial control systems can be manipulated into taking an action that falls within its permissions yet was never meant to happen, and no access control can stop it, because from the system’s perspective, every credential is valid, every process is normal, and no rule has been broken.

The five threats unfolding right now all target the same blind spot: what is actually hiding behind operations that look entirely legitimate.

Article content

This is the blind spot most easily overlooked in this era. A conventional question answering AI only responds to input typed directly by a user. An AI agent is different: it browses the web, reads documents, and queries databases on its own initiative, gathering information and taking action autonomously. This capability opens an entirely new attack surface. An attacker only needs to embed a hidden instruction for the agent inside a web page, an email attachment, or a shared document. The root cause is a fundamental technical limitation: Microsoft Research has confirmed that large language models cannot reliably distinguish between text that is merely reference material and text that constitutes an instruction to be executed. The user never sees the malicious instruction, yet the agent treats it as a legitimate request and carries it out. When an agent is granted access to external files or industrial databases and integrated with MES, ERP, or OT control systems, the consequences escalate sharply. Research published in the journal Information (MDPI) in January 2026 found that in industrial control settings, the potential impact of this class of attack extends well beyond data exfiltration into direct manipulation of production systems. A Center for Internet Security report from April 2026 recorded a 340% year over year increase in related attacks, and the OWASP GenAI Security Project ranks prompt injection as the top threat to agentic AI.

Every tool an agent can call opens another door an attacker might exploit. An attacker can tamper with a tool’s description or interface, tricking the agent into trusting a compromised tool and executing an unauthorized action, a technique known as tool poisoning. Alternatively, an attacker can leave a tool clean for a period of time, then swap in a malicious version once the agent has come to trust it, a technique known as a rug pull. Anthropic has documented a real world case: the first malicious MCP server ever discovered in the wild posed as a legitimate email service while secretly copying every message the user sent. Harder still to detect is tool chaining. Viewed individually, an internal CRM lookup tool and an external email tool are each perfectly safe, but an attacker can induce the agent to chain them together, pulling customer records with the CRM tool and exfiltrating them through the email tool. The entire sequence runs on legitimate credentials through normal program execution, so conventional malware monitoring detects nothing at all.

Beyond tampering with the tools themselves, an agent’s automated nature can also be exploited directly. A human operator grows fatigued with repetitive tasks and pauses to check in, but an agent does not. As long as its logic concludes that one more query is warranted, it will keep triggering the next call. An attacker needs only to trap the agent in a loop, repeatedly invoking a costly external API, to cause a service outage or a runaway cloud bill within minutes. The entire attack is self triggered by the agent, requires no human intervention, and does not need to breach any system at all. It is often noticed only after the bill or the service alert arrives, a textbook case of legitimate functionality being overused rather than a conventional intrusion.

A common failure in multi agent systems is unscoped privilege inheritance: a high privilege manager agent delegates a task to a worker agent without applying least privilege scoping, passing along its full access rights unchanged. A related variant is the confused deputy problem: a lower privilege agent forwards an instruction that appears legitimate to a higher privilege agent, which executes it without verifying the original user’s intent. Risk can also hide in memory. If an agent caches credentials or keys from a prior session for reuse without proper memory segmentation, an attacker can prompt it to retrieve those residual credentials and carry out actions its own credentials would never permit, effectively escalating privilege across session boundaries. When multiple agents routinely trust and delegate to one another, these gaps widen further, and reconstructing which delegation caused the breach often only happens after the fact.

Agentic systems differ from traditional software in that they frequently assemble capabilities at runtime, loading external tools and switching between models or personas on the fly, which pushes the attack surface beyond what traditional software supply chain analysis can handle. The risk operates on two layers. One lies in the model itself: if training data or the fine tuning process is tampered with, a backdoor can survive the entire deployment lifecycle. Anthropic’s own research found that injecting just 250 malicious documents is enough to plant a backdoor in models ranging from 600 million to 13 billion parameters, and that backdoor persists even after subsequent safety training, including supervised fine tuning and RLHF. The other layer lies in tools and frameworks: the PyTorch dependency confusion attack showed how malicious packages can exfiltrate SSH keys during installation, and security researchers have identified roughly 100 malicious AI models on major platforms, some of which open a reverse shell the moment they are loaded. A model’s provenance, where its training data came from and whose hands it passed through, is itself an attack surface that warrants scrutiny.

Agents retain records of past interactions to become more useful, but without proper isolation, a single successful injection can poison every future session, leaving the agent to carry out an attacker’s planted instructions indefinitely. Contamination can arrive through more than one channel. If an agent relies on a vector database for retrieval (RAG), poisoned sources, direct uploads, or an overly trusted data pipeline can all introduce malicious data into that database, and anything the agent later retrieves from it can produce false answers or execute a planted payload. In multi tenant environments, contamination can also spread through shared context, passing from one user’s session into another’s.

These poisoning techniques can still be traced back to a single identifiable event. Long term memory drift is a harder to detect variant. It does not rely on one successful injection but instead works through summarization or feedback from other agents, gradually and quietly distorting the knowledge or goal weighting an agent has stored. Because each individual change looks harmless in isolation, perhaps a slight shift in how a summary is worded or a minor adjustment in weighting, conventional anomaly detection struggles to flag any single instance. It is typically only noticed once the agent’s behavior has visibly drifted from its original scope, and by then the drift may have been accumulating for a long time.

Having read through these five threats, it is easy to fall into a particular kind of anxiety: does every new attack technique require a new corresponding defense? Follow that logic and you will spend forever chasing attackers, because new techniques keep emerging faster than any team can patch for them. The real question is different: is there a set of principles that holds regardless of what new technique appears next, so that as long as the principles are upheld, the defense holds too.

If a service account’s access were scoped down from the outset to the minimum dataset its task actually requires, then even if it were manipulated into an anomalous action, the blast radius would already be confined to a small perimeter. The breach happens, but the damage is contained. That is an achievable defensive posture: not preventing every breach, but ensuring a breach never becomes the start of a disaster.

In the next installment, we break down a systematic framework for putting this into practice: eight capability domains across three tiers of maturity, showing exactly what a defense architecture built to withstand the agentic AI era looks like.

When Attackers Also Wield AI Agents, the Ground Beneath Enterprise Defense Starts to Shift Read More »