[Agentic AI Governance 03] Security for Agentic AI

This is the third article in the five-part Agentic AI Governance series. Parts 1 and 2 introduced the Zero Trust for AI framework and traced shadow AI’s evolution into shadow agents. This piece is the full picture — the numbers, OWASP’s Top 10 for Agentic Applications, and a 90-day plan. Parts 4 and 5 go deeper on the AI firewall and data governance.

Key Takeaways

• IBM's 2026 breach report shows AI-enabled breaches are up 56% year over year and cost about USD 6 million on average — but most of that cost is no longer coming from employees pasting text into a chatbot.
• The security boundary has moved from what a model says to what an agent does. Three structural shifts — tools as a new supply chain, memory that outlives the session, and privilege exercised with no human present — combine into the “lethal trifecta”: private data access, untrusted content exposure, and a means of communicating externally.
• OWASP's Top 10 for Agentic Applications (ASI01–ASI10) maps the new attack surface into four practical clusters: input & memory, action & tools, identity & privilege, and dependencies & orchestration.
• The EU AI Act's Digital Omnibus pushed high-risk obligations back to December 2027 and August 2028 — but Article 50 transparency duties still apply from 2 August 2026. The deferral moved the deadline; it did not remove it.
• This is not a Europe-only problem: South Korea's AI Basic Act and Taiwan's AI Risk Classification Framework are already in force, and Texas ties documented NIST AI RMF alignment to a legal safe harbour.
• Nine concrete questions — from agent discovery to data residency — give security leaders a vendor-assessment checklist, and a pragmatic 90-day sequence (inventory, rank by blast radius, fix identity, turn on logging, rehearse containment) turns the checklist into a rollout plan.

1. Start with the numbers

In July 2026, IBM published its Cost of a Data Breach Report 2026. Three findings deserve a seat at the board table.

• One in four malicious breaches is now AI-enabled — a 56% increase year over year. These breaches cost an average of USD 6 million, roughly USD 1 million more than the USD 4.99 million global average.
• The share of security incidents involving shadow AI more than doubled in a single year, to 43%.
• More than two-thirds of organisations still have no governance process to manage AI or detect shadow AI. Only 38% require IT approval before AI is deployed — down from 45% the year before.

Mean time to identify and contain a breach now stands at 247 days, six days longer than the previous year.

Figure 1 — Three headline numbers from IBM's Cost of a Data Breach Report 2026: a 56% year-over-year rise in AI-enabled breaches, a 43% share of incidents involving shadow AI, and a 247-day mean time to identify and contain.

Here is the uncomfortable part. Most of that cost is not being generated by employees pasting confidential text into a chatbot.

For two years, enterprise AI policy has been written to prevent precisely that: no customer records in ChatGPT, no confidential documents uploaded, unsanctioned AI domains blocked at the gateway. None of it was wrong. All of it was designed for the 2023 threat model — not for what agentic AI security has to cover now.

The question in 2026 is no longer what your AI knows. It is what your AI can do.

2. What changed: from answering to acting

The defining difference between an agentic system and a chatbot is not that the agent is smarter. It is that the agent acts. It calls tools, queries and writes to databases, sends email, executes commands, chains steps across systems, and carries memory from one session into the next.

That single change relocates the security boundary.

Three structural shifts sit underneath that table.

Tools are the new supply chain. Agents reach external systems through mechanisms such as the Model Context Protocol (MCP). Every connected tool, every tool description, every third-party MCP server is a path that can be poisoned. Your AI security now depends on other people's code that you have never reviewed.

Memory outlives the session. A classic prompt injection ended when the conversation ended. Once an agent holds long-term memory and a vector store, a single successful memory poisoning attack can lie dormant and fire days later during an unrelated task. The attack shifts from one-shot to persistent.

Privilege is exercised with no human present. An agent typically runs carrying its creator's permissions, often in unattended scheduled work. Traditional security assumes that the exercise of privilege is accompanied by a person's judgement. In agentic architectures, that assumption no longer holds.

Put the three together and you arrive at the lethal trifecta, as described in Part 1: private data access, untrusted content exposure, and a means of communicating externally, all present at once.

Figure 2 — The lethal trifecta, as introduced in Part 1. When a system has all three conditions at once, data exfiltration is a matter of time.

Same three conditions, new context: here they combine with the structural shifts above to define the agentic attack surface OWASP now catalogues.

3. Three ways AI and security now intersect

Three things are routinely conflated. They are worth separating before going further.

AI for Security.

Using AI to strengthen defence — anomaly detection, malware classification, alert triage and incident summarisation in the SOC. Here AI is the tool.

Security for AI.

Ensuring that AI systems are themselves developed, deployed and used safely: models, training data, tool chains, agent privilege, audit trails. Here AI is the asset being protected — AI agent security sits inside this category. This paper is about this one.

AI as the adversary.

The third leg, which only fully materialised in 2026. Attackers run agents too — automated reconnaissance, deepfake impersonation, AI-assisted malware. IBM's data puts AI-enabled intrusions at a quarter of all malicious breaches.

The relationship between them matters. Because the third is happening, the first has become necessary. But if the second is neglected, the first will enlarge your attack surface rather than reduce it — your security AI is itself a highly privileged agent.

Figure 3 — Three ways AI and security now intersect: AI for security, security for AI, and AI as the adversary.

4. What the new attack surface looks like

In December 2025 the OWASP GenAI Security Project published the Top 10 for Agentic Applications (2026 edition), updated to v2.01 in June 2026. It is the first OWASP flagship list written for software that acts rather than for the models that power it. Entries are numbered ASI01 to ASI10.

Decision-makers do not need all ten. Four clusters are enough to reason with.

Figure 4 — The four clusters of agentic risk, grouping OWASP's Top 10 for Agentic Applications into input & memory, action & tools, identity & privilege, and dependencies & orchestration.

The dependency cluster is where 2026 moved fastest. Three disclosed protocol-layer events illustrate the character of the problem.

• An MCP package named postmark-mcp shipped fifteen clean releases to build community trust before quietly adding a single line of exfiltration code — the first confirmed malicious MCP package observed in the wild. The technique is standard software supply-chain tradecraft, relocated into the AI tooling ecosystem.
• CVE-2025-6514 (CVSS 9.6) was a remote code execution flaw in core MCP infrastructure used across hundreds of thousands of developer environments.
• In April 2026, research disclosed a command injection weakness in the STDIO transport of the official MCP SDKs, where configuration parameters reached the host shell without sanitisation.

What these three share is worth noticing: none of them was a model failure. No jailbreak, no harmful generation. What broke was the plumbing around the model. That is why two years of investment in content filtering and prompt guardrails does not convert directly into agentic defence.

One further risk is chronically underestimated: ASI09, human-agent trust exploitation. When an agent produces several hundred plausible-looking results a day, human review degrades into rubber-stamping. The attacker does not need to defeat the system. Only the tired person approving its output.

5. Why this is harder in practice

Shadow AI has become shadow agents

Shadow AI used to mean employees using unsanctioned tools. The problem has moved up a level: business functions are no longer only using AI, they are building agents.

Low-code agent builders let marketing, HR or finance assemble an agent in an afternoon that reads a mailbox, queries a database and replies automatically — with IT entirely unaware. Gartner expects 40% of enterprise applications to embed task-specific AI agents by the end of 2026, up from under 5% in 2025.

Deloitte's State of AI in the Enterprise (January 2026, N = 3,199) traces the same curve: organisations expect moderate-or-greater use of AI agents to rise from roughly a quarter today to nearly three-quarters within two years. In the same study the leading concerns were data privacy and security (73%), legal, IP or regulatory compliance (50%), and governance capability and oversight (46%) — every one of them owned by the security function.

An unsanctioned chatbot account leaks data. An unsanctioned agent takes action. That is a difference in kind, not degree.

Your existing controls cannot see this layer

DLP and CASB were designed to inspect traffic between a person and an application. The decisive traffic in an agentic architecture runs agent-to-tool and agent-to-agent: encrypted API calls carrying structured function arguments, largely generated by automated schedules. Those tools are not misconfigured. They simply do not have that vantage point.

The regulatory position has shifted — and the delay is not a reprieve

The EU AI Act timeline was reset when the Digital Omnibus on AI was adopted by Parliament on 16 June 2026 and by Council on 29 June 2026, entering into force in July. The current position is more nuanced than the headline “the EU delayed the AI Act” suggests:

• Article 50 transparency obligations apply from 2 August 2026, as originally scheduled.
• Article 50(2) content-marking for systems already on the market, and the newly added prohibited practices, apply from 2 December 2026.
• High-risk obligations for stand-alone Annex III systems move to 2 December 2027; for AI embedded in Annex I regulated products, to 2 August 2028.

Article 4 AI literacy obligations have applied since February 2025 and were not deferred. Neither was the direction of travel for high-risk systems: Article 12 record-keeping and Article 14 human oversight remain the substance of what providers and deployers will have to evidence. Attributable, tamper-evident logging of agent actions is an eighteen-month engineering programme, not a three-month one. The deferral moved the wall back. It did not remove it.

GDPR is the more immediate constraint, and agentic architectures raise questions the standard AI DPIA template does not yet ask:

• Data minimisation and purpose limitation (Art. 5). An agent that pulls context broadly across connectors to complete a task will, by design, retrieve more personal data than the task strictly requires.
• International transfers (Chapter V). When an agent routes connector content to a model, the inference location becomes a transfer question. Most organisations can answer this for their SaaS estate and cannot yet answer it for their agents.
• Records of processing (Art. 30) and DPIA (Art. 35). Autonomous, repeated, cross-system data movement is a processing activity that has to be described — which is impossible without action-level logs.
• Controller and processor roles. These blur when one agent delegates to another across chained services. Clarify them contractually before deployment, not after an incident.

The direction is not EU-only

Anyone treating this as a European problem should note that two Asian jurisdictions reached enforcement before the EU's high-risk regime will.

• South Korea. The AI Basic Act and its Enforcement Decree took effect on 22 January 2026, making Korea the second jurisdiction after the EU with a comprehensive AI statute. It applies extraterritorially to foreign providers serving Korean users, imposes transparency, high-impact and record-keeping duties, and requires larger foreign providers to designate a domestic representative. MSIT is operating a grace period of at least a year on administrative fines — a deferral of penalties, not of obligations.
• Taiwan. The AI Basic Act came into force in January 2026, and on 7 July 2026 the Ministry of Digital Affairs published its AI Risk Classification Framework v1.0, organising known risks into three categories and twenty sub-categories. One of those sub-categories is named “unauthorised actions by autonomous AI agents” — a notably early instance of an agent exceeding its authority appearing as a named entry in an official risk taxonomy rather than in a security vendor's threat model.
• United States. No federal statute. Texas's TRAIGA and California's SB 53 took effect on 1 January 2026; Colorado repealed its 2024 AI Act and replaced it with a narrower automated-decision statute effective January 2027; Executive Order 14365 has pushed for federal preemption without settling it. Texas grants a safe harbour for substantial compliance with the NIST AI Risk Management Framework — which turns documented framework alignment into a legal defence rather than merely good practice.

For a multinational, the practical consequence is not that four regimes have to be satisfied separately. It is that the compliance floor is set by whichever jurisdiction moves first, and that the underlying control requirements converge on the same short list: an inventory of AI systems, risk classification, human oversight of consequential decisions, and durable records of what the system actually did. Those are engineering artefacts, not legal ones. Build them once and the mapping to each regime becomes a documentation exercise rather than a separate programme.

Figure 5 — Why this is harder in practice, in four parts.

6. What to look for in a platform: nine questions

The familiar checklist — zero trust, data isolation, audit logging — points in the right direction but stops at the granularity of users and data. Agentic architecture requires it to extend down to agents and actions. The following nine questions can be used directly in a vendor assessment.

• 1. Agent discovery. Can you enumerate every agent operating in your environment, including departmental automations, browser extensions, SaaS-embedded agents and MCP connections? You cannot govern what you cannot see.
• 2. One identity per agent, not a shared key. An agent should be treated as a non-human identity with its own credential, lifecycle and audit trail. Shared API keys make “who did this” permanently unanswerable.
• 3. Least agency, not just least privilege. Least privilege asks what an agent may read. Least agency asks what it may do. An agent that summarises documents should not hold the ability to send mail, even where it may lawfully read the mailbox.
• 4. A trust boundary between instructions and retrieved content. System prompts, user instructions and retrieved external content must be architecturally separated, and writes to long-term memory validated. This is the root control against goal hijack and memory poisoning.
• 5. Tool and MCP supply-chain governance. Allowlisting, version pinning, provenance verification, and review of changes to tool descriptions — because an agent decides whether to call a tool based on its description, so altering the description alters behaviour without touching a line of code.
• 6. Observability at the action layer. The unit of logging must be the individual tool call, inter-agent message and delegation, attributable to a specific agent and a specific authority, and tamper-evident. Conversation logs alone are insufficient — and insufficient for the record-keeping obligations above.
• 7. Containment. Budget ceilings, rate limits, concurrency caps, circuit breakers and a kill switch. These look like cost controls. They are security controls: they determine the blast radius of any failure.
• 8. Human oversight placed where it counts. Not approval at every step, which degrades into rubber-stamping, but human judgement reserved for irreversible, high-impact actions: payments, external communication, deletion, permission changes.
• 9. Data residency and model routing. For any organisation processing EU personal data, this may outweigh the preceding eight. Can you pin processing to a named region? Can you constrain which models an agent may route to, and evidence where inference occurred? Ask for the answer in writing.

Figure 6 — What to look for in a platform: nine questions for a vendor assessment.

What this looks like in practice

AnyInsight offers a concrete illustration of these criteria in operation. One point deserves to be stated plainly first: AnyInsight's connectors use MCP as their underlying protocol, linking to more than 500 external systems including Gmail, Outlook, Jira, Slack and Salesforce. The MCP risks described in section 4 are therefore not somebody else's problem. They are a question any platform of this design has to answer directly.

The answer is to route MCP traffic through the same checkpoint as human traffic.

• Identity precedes action. A three-tier Organisation / Workspace / User hierarchy resolves who is acting and within what scope before a request proceeds. Workspace roles — Owner, Admin, Contributor, Auditor, User — are least-privilege by default. AnyInsight calls the result a walled workspace: lateral movement between, say, R&D and legal is severed architecturally rather than by policy alone.
• Least agency is enforced at the same plane as least privilege. Administrators assign models, agents, templates and connectors from a central resource hub to specific workspaces. Deciding which tools an agent may call is the same control surface as deciding which data it may read — which is exactly what criterion 3 asks for.
• Inline inspection runs in both directions. The GenAI firewall sits between users, workflows and models. On egress it identifies and masks sensitive data and intercepts non-compliant input. On ingress it inspects content returned by models and by connectors — the latter being the most common carrier of indirect prompt injection, and the most commonly overlooked.
• The connector log is the action-layer record. Of the five audit log types, the connector log captures every operation an agent performs against an external system through a connector. This is criterion 6, and it is the most direct control against shadow-agent risk: not trusting the agent, but placing the same governed checkpoint on the agent's data movements as on a person's.
• Evidence is retained for completeness, not for compliance status. The Data Vault preserves every interaction whether or not it violated a policy, on the principle that an audit is only as trustworthy as its evidence is complete. Logs that record only violations are frequently inadequate during investigation.
• The policy engine grades its response. Policies span content filtering, PII, financial data, credentials, health data and access control (device, operating system, geolocation, IP/CIDR, time window). Rules carry priority, enabled state and allowlist or blocklist exceptions. On match, the engine applies Alert, Block or Mask and writes the outcome to the Moderation Record with violator context, rule and severity for a named administrator to resolve.

Two boundaries should be stated honestly. On criterion 1, a platform of this kind inventories the models, agents and connectors used within it; automations, browser extensions or private MCP servers that employees stand up elsewhere are addressed by reducing the incentive to build them — offering a sanctioned option good enough that nobody wants to route around it — rather than by detecting them. Enterprise-wide agent discovery still requires network-layer visibility alongside, which is why AnyInsight pursues joint defence with network security vendors.

On criterion 9, ask for specifics rather than assurances. AnyInsight is delivered multi-region and multi-cloud on AWS infrastructure, with European deployment available in the AWS eu-central-1 (Frankfurt) region — so processing can be pinned to EU territory rather than merely asserted to be adequate. That is the level of specificity a Chapter V analysis requires, and it is the answer worth demanding from every vendor on a shortlist.

On MAIA: a quality control, not a security control

The platform's Multi-AI Architecture (MAIA) offers three collaboration modes: Parallel, in which two models execute the same task independently to counter single-model bias; Integrative, in which a second model dynamically incorporates enterprise data; and Critique, in which a second model reviews and challenges the first model's conclusions. For legal review, financial analysis and comparable high-impact judgements, this measurably reduces hallucination and single-point bias.

Its position should nonetheless be stated precisely: this is a quality control, not a security control. Multi-agent designs are themselves governed by ASI07 (inter-agent communication) and ASI08 (cascading failures). If messages between agents can be forged, cross-checking amplifies one error into a consensus. Multi-model review has to rest on protected communication and attributable identity. The two are complementary, not substitutes.

A note on verifiable credentials

One criterion sits outside the nine and should not be skipped: what a vendor asserts and what a vendor has had independently audited are different things. Require the two to be listed separately. AnyInsight holds ISO/IEC 27001 certification and runs on cloud infrastructure certified to ISO/IEC 27001, 27017 and 27018; ISO/IEC 42001, the AI management system standard, is on the roadmap for adoption in 2027. That distinction — certified today, planned for a stated date — is precisely the form of answer worth insisting on, because ISO/IEC 42001 is now appearing in European procurement questionnaires with increasing frequency and a vendor unable to state its position is telling you something.

7. A pragmatic first 90 days

If you are starting now, this sequence works.

• Weeks 1–2 — Inventory. List every agent, the tools each can call, and the identities and permissions each holds. Include what departments built themselves. This step almost always surfaces more than expected.
• Weeks 3–4 — Rank by blast radius. Not by importance, but by what happens if this agent is hijacked. Anything that can delete data, move money or communicate externally is tier one.
• Weeks 5–8 — Fix identity and scope. Retire shared keys, one identity per agent, short-lived credentials, and tighten tier-one tool scope to the minimum.
• Weeks 9–10 — Turn on action logging. Every tool call and delegation, attributable and tamper-evident. This is simultaneously a security requirement and a regulatory one.
• Weeks 11–12 — Rehearse containment. Actually press the kill switch once and measure the time from anomaly detected to agent stopped. An untested kill switch is not a control.

Figure 7 — A pragmatic first 90 days: inventory, rank by blast radius, fix identity and scope, turn on action logging, and rehearse containment.

Throughout — policy plus enablement. This is the step most often skipped and the one that decides the outcome. Prohibition alone does not work; IBM's figures already demonstrate it, with two-thirds of organisations lacking governance and the proportion requiring pre-deployment approval falling rather than rising. Productivity pressure beats policy. When an employee's work requires AI and the sanctioned option is poor, they will route around it. Governance therefore begins not with a prohibition but with a sanctioned option good enough that nobody wants to avoid it. A policy without a usable alternative behind it is a disclaimer, not a control.

8. Conclusion

For two years, AI security has been treated as a brake on productivity: let people adopt it first, secure it later.

Under agentic architecture that trade-off no longer exists. An agent with no identity, no scope constraint, no action log and no stop mechanism is not faster-but-riskier. It is unable to be deployed at scale at all — because the first incident will halt the entire programme, and you will have no way to reconstruct what happened.

The organisations that resolve identity, scope, audit and containment are the ones that can move agents out of pilot projects and into core processes. Security is not the price of productivity. It is the precondition for it.

For security and compliance leaders evaluating enterprise GenAI and agent platforms, AnyInsight by HEARTBOT is built to deliver productivity and governance as one system rather than as a trade. The full architecture, policy engine, audit model and a mapping to EU AI Act, GDPR and ISO/IEC 27001 obligations are set out in the AI Governance & Compliance Overview technical whitepaper, available on request at anyinsight.ai.

If you are already dealing with shadow agents in your own estate, that experience is worth sharing — it is a problem far more organisations have than currently admit.

Figure 8 — Security is the precondition for productivity, not the price of it.

The Agentic AI Governance Series, Start to Finish

Part 1 — Zero Trust for AI: The 5-Checkpoint Framework for AI Agents

Part 2 — From Shadow AI to Shadow Agents: The Gap in Your AI Policy

Part 3 — Security for Agentic AI ← You are here

Part 4 — Filtering Prompts Is Not Governing AI

Part 5 — When AI Starts Fetching Its Own Data