Behavry Research

The Agentic AI Governance
Blind Spot Taxonomy

A structural analysis of what 50 agentic AI security vendors cannot see, and why each blind spot is architectural, not a roadmap gap.

Ward Spangenberg · Founder and CEO, Behavry Inc.
PublishedApril 2026
Last updatedApril 2026
Updated quarterly.
Executive Summary

The market produces capability matrices.
None publishes a structural map.

The agentic AI security market has produced at least 83 distinct vendors in under 24 months. Every vendor publishes capability matrices. None has published a rigorous map of what their architecture structurally cannot see.

This document does exactly that.

Across 50 companies tracked by Behavry, we identify nine recurring architectural patterns. Each pattern has a structural blind spot. A class of risk it cannot address regardless of how mature the product becomes. These are not roadmap gaps. They are consequences of where the vendor chose to sit in the stack.

The central finding: every pattern except inline pre-execution enforcement fails to address the same problem. The tool call that already executed. And every pattern except one inherits a second structural flaw: the entity that acts is also the entity that attests to its own behavior.

That is not governance. That is forensics with a compliance badge.
Principle

The Attestation Separation Principle

The philosophical anchor for this analysis is a single structural requirement.

The entity that acts cannot attest to its own behavior.

When an AI agent logs its own actions, generates its own audit trail, and reports itself as compliant, the compliance record is produced by the same system being governed. This is structurally equivalent to a defendant writing their own verdict.

Every architecture that instruments the agent itself, including SDK hooks, eBPF sensors, sidecar monitors, and LLM-layer guardrails, inherits this flaw. The agent is the source of truth about what the agent did. The observer and the observed are the same entity.

An inline governance layer positioned between the agent and its tools is the only architectural position from which chain-of-custody can be independently attested. The proxy acts; it is never the agent. Its log is produced by a separate system. That separation is the structural moat.

Patterns

The Nine Blind Spot Patterns

The following patterns are derived from public architectural claims, documentation, and investor materials for each vendor. We take each vendor at their word and draw the structural implications.

PATTERN 01

LLM / Prompt Layer Firewall

Governs what goes into and out of the model. Invisible to everything the model decides to do.

How it works
Intercepts user prompts and model outputs via API. Scans for prompt injection, jailbreaks, PII, toxic content. Routes through a detection engine before the model sees the input or the user sees the response. Typically deployed as a REST API wrapper or SDK integration.
Enforcement point
Model input / model output boundary. The firewall operates in the conversation layer, not the execution layer.
Structural blind spot
Everything below the model. Once the LLM decides to invoke a tool, the firewall has no jurisdiction. Tool calls, database reads, file writes, API calls, external HTTP requests, and multi-step agent chains are all invisible. The firewall saw the prompt that asked for the action. It cannot see the action itself.
Attestation flaw
The model is still the source of its own execution log. Even if the firewall catches a bad prompt, a successfully evasive prompt produces an agent action with no governance record from the firewall. The agent attests.
Incident class cannot prevent
Data exfiltration through legitimate tool calls. Privilege escalation via authorized API. Indirect prompt injection delivered through retrieved documents after the initial prompt cleared the firewall.
Representative vendors
Lakera (Guard) · CalypsoAI (Inference Platform) · Prompt Security (AI Firewall) · Cato Networks (AI-FW module)
PATTERN 02

Supply Chain / Artifact Governance

Governs what software reaches the endpoint. Cannot govern what authorized software does once it runs.

How it works
Scans MCP servers, extensions, plugins, agent skills, and packages before they are installed or deployed. Checks for malicious code, excessive permissions, known vulnerabilities, and supply chain tampering. Maintains an approved artifact registry. Block rules prevent unauthorized artifacts from reaching the runtime.
Enforcement point
Pre-install / pre-deployment. The enforcement point is the artifact boundary, not the execution boundary.
Structural blind spot
Everything the authorized artifact does after it is installed and running. An MCP server that passed every supply chain check can still be manipulated at runtime to exfiltrate data through legitimate tool calls. The artifact was vetted. The session was not.
Attestation flaw
Post-deployment activity is logged by the agent runtime or the MCP server itself. The supply chain governance layer has no visibility into what the vetted artifact does in production. The agent attests.
Incident class cannot prevent
Runtime prompt injection against a vetted MCP server. Authorized tool used to exceed task scope. Credential harvesting through a clean artifact with legitimate API access.
Representative vendors
Koi / Palo Alto Networks · Cisco DefenseClaw (open source, RSAC 2026) · Cycode (agentic dev security) · Enkrypt AI (AI supply chain posture)
PATTERN 03

Identity / JIT Access Control

Governs who the agent is and what it can reach. Cannot govern what it does once it gets there.

How it works
Provisions time-bound, least-privilege credentials for AI agents. Issues short-lived OAuth tokens, service principal identities, or API keys scoped to specific tasks. Revokes credentials automatically after session completion. Governs agent identity lifecycle: registration, onboarding, deprovisioning. Enforces zero standing privilege (ZSP).
Enforcement point
Credential provisioning layer. Enforcement occurs at the moment of access grant and revocation, not at the moment of tool-call execution.
Structural blind spot
Everything the agent does inside the authorized access window. A JIT-provisioned agent with scoped Salesforce credentials can still read every contact, compress the output, and transmit it externally, all within the provisioned session. The identity layer sees the session open and the session close. It does not see what happened in between.
Attestation flaw
The audit trail records which agent received which credential, when. The audit trail of what the agent did with that credential is produced by the downstream system (Salesforce, AWS, the database), not by the identity provider. The agent and its runtime attest.
Incident class cannot prevent
Data exfiltration through legitimate, properly scoped credentials. Lateral movement within the authorized access window. Cascade of tool calls that individually appear authorized but collectively constitute a policy violation.
Representative vendors
Oasis Security · Ping Identity (Identity for AI) · CyberArk (Secure AI Agents + AI Agent Gateway) · Aembit (workload identity, secretless) · SGNL / CrowdStrike (continuous authorization, ZSP) · Astrix Security (NHI + Agent Control Plane) · Hush Security (NHI + secretless) · Keycard (agent identity infra) · Agentic Fabriq · Cyata
PATTERN 04

Observe-and-Detect / Runtime Monitoring

The dominant pattern. Watches everything. Prevents nothing. Produces forensics, not governance.

How it works
Instruments the agent via SDK hooks, eBPF sensors, IDE extensions, or sidecar proxies. Collects traces, model calls, tool invocations, and network requests. Applies behavioral anomaly detection, policy violation scoring, and threat pattern matching. Generates alerts, dashboards, and incident tickets when suspicious behavior is detected.
Enforcement point
Post-execution log analysis. Even "real-time" detection in this pattern means the tool call completed before the alert fired. Enforcement is reactive: suspend, disable, escalate after the fact.
Structural blind spot
Prevention. The structural limit is not detection latency. It is that detection occurs after the execution path has run. A 300ms detection latency is irrelevant when 124,000 records were transmitted in 200ms. The architecture cannot prevent what it is designed only to observe.
Attestation flaw
The monitoring agent is instrumented into the same runtime as the governed agent. SDK hooks run in the same process. eBPF sensors read from kernel telemetry produced by the agent's own execution. The most explicit case: Straiker's MCP-based guardrail is a tool the agent calls to check itself. The agent is the attestor.
Incident class cannot prevent
Any incident that produces irreversible consequences faster than detection latency. Data exfiltration. Wire transfer initiation. Destructive write operations. Evidence deletion. All produce a detailed forensic record and zero prevention.
Representative vendors
Noma Security · Straiker (Defend AI) · AllTrue.ai / Varonis · Acuvity / Proofpoint (RYNO platform) · Zenity (AI-SPM) · Portal26 (GenAI visibility) · Geordie AI (observe-and-guide) · Capsule Security · Manifold (Endpoint AIDR) · Knostic / Kirin
PATTERN 05

MCP Gateway / Access Registry

Governs which tools agents can access. Partially blind inside authorized connections.

How it works
Maintains a registry of approved MCP servers. Enforces authentication (SSO, OAuth) at the connection boundary. Routes agent tool calls through a managed proxy that validates identity and server authorization. Some implementations add content inspection on MCP traffic. Maps agent permissions to human user permissions.
Enforcement point
Connection authorization layer. The gateway enforces: is this agent allowed to connect to this MCP server? More advanced implementations add TBAC (task/tool/transaction-based access control) at the method level.
Structural blind spot
The authorized connection scope. Once an agent has a valid connection to an approved MCP server, what it does within that connection depends on how granular the gateway's method-level controls are. Most implementations authorize at the server level, not the tool-call parameter level. An agent authorized to use a Salesforce MCP server can query any object the MCP server exposes, regardless of the task it was assigned. The gateway governs the door. Not what happens inside the room.
Attestation flaw
The gateway log records connection events and, in some cases, tool call routing decisions. The actual tool call execution, including what parameters were passed, what data was returned, and what the agent did with the response, is recorded by the downstream MCP server and the agent runtime. The agent attests to its own execution.
Incident class cannot prevent
Within-scope data overreach (agent reads more than needed from an authorized connection). Cross-server data correlation (agent calls multiple authorized MCPs to assemble sensitive data). Parameter-level policy violations within authorized methods.
Representative vendors
Runlayer · Traefik Labs (Triple Gate MCP Gateway) · MintMCP · Onyx Security · JetStream Security · Akto (API/MCP)
PATTERN 06

Platform-Native Governance

Strong governance within one platform. Zero visibility outside it.

How it works
Governance capabilities built directly into an AI development or deployment platform. Includes RBAC on tools, data, and models; lineage tracking from data to output; guardrails for content and PII; rate limiting; compliance dashboards. Agents built using the platform's native frameworks inherit governance automatically.
Enforcement point
Within-platform policy engine. Enforcement is comprehensive for agents built on and deployed within the platform. Governed by the same data catalog and policy engine that governs the rest of the platform.
Structural blind spot
Every agent that was not built on, or is not deployed within, the platform. Shadow agents, homegrown agents, third-party agents, and any agent that accesses the platform's data through an external integration are invisible. Additionally: the platform that governs also produces the audit record. The lineage log is generated by the same system executing the agent. This is the clearest case of platform self-attestation.
Attestation flaw
The platform writes the audit log. The platform executes the agent. The platform validates compliance. There is no third party in the attestation chain. If the platform is compromised or misconfigured, its own audit trail is the only record. The platform attests.
Incident class cannot prevent
Shadow agents accessing platform data via external API. Third-party agents with direct database connections. Any agent operating outside the platform's observability perimeter. Insider threats using platform-native agents to access data outside their authorized scope.
Representative vendors
Databricks (Unity Catalog + Unity AI Gateway) · Kore.ai (enterprise AI orchestration) · TrueFoundry (agentic AI gateway + LLM platform) · Sana (AI knowledge platform) · Arkeo AI (on-premise private AI)
PATTERN 07

Red Team / Adversarial Testing

Finds vulnerabilities before deployment. Provides zero runtime enforcement.

How it works
Automated adversarial probing of AI agents and applications. Simulates real-world attack patterns: prompt injection, jailbreaks, goal hijacking, data extraction. Generates vulnerability reports, attack success rates, and remediation guidance. Some platforms provide continuous red teaming. Separate from runtime governance.
Enforcement point
Pre-deployment testing environment. Red teaming is a quality gate, not an enforcement mechanism. It answers: how does this agent behave when attacked? It does not answer: what is this agent doing right now?
Structural blind spot
Live runtime enforcement. Red teaming cannot prevent an agent from being exploited in production by a novel attack vector, a zero-day, or a context-specific manipulation that was not included in the test corpus. Production agents face real users with real adversarial intent in real time. The test environment cannot fully replicate that.
Attestation flaw
Not applicable. Red team tools do not produce governance records for production systems. Their attestation value is limited to: we tested this agent before deployment.
Incident class cannot prevent
Novel attack vectors discovered after deployment. Zero-day prompt injections. Context-specific manipulations that bypass tested controls. Production attacks that succeed because they differ from the test corpus.
Representative vendors
Straiker (Ascend AI, continuous red team) · SPLX (red team + runtime) · Novee (AI penetration testing) · IriusRisk / ThreatModeler (threat modeling) · Enkrypt AI (AI security testing)
PATTERN 08

Workforce AI Governance

Governs which AI tools employees can use. Cannot govern what autonomous agents do.

How it works
Discovers AI tools being used across the organization, including unsanctioned "shadow AI". Enforces policies on which AI services employees are allowed to access. Browser-based enforcement intercepts AI-related traffic. Provides dashboards of AI usage by team, application, and data type. Focused on the employee-facing AI surface.
Enforcement point
Employee AI tool access control. The enforcement boundary is which AI services a human employee is allowed to reach. Browser extensions or network proxies enforce the approved AI tool list.
Structural blind spot
Autonomous agent behavior. These tools govern humans using AI. When agents operate autonomously on behalf of humans, making calls to APIs, tools, and services without human-in-the-loop review, the workforce governance layer has no visibility or control. An employee's approved use of Claude does not govern what a Claude agent deployed by that employee does at 3am.
Attestation flaw
Workforce governance logs record employee interactions with AI tools. They do not record autonomous agent actions taken outside the employee interaction. The autonomous agent operates in a governance gap.
Incident class cannot prevent
Autonomous agents operating outside scheduled human oversight. Shadow agent deployment by employees using approved AI tools. Agentic workflows triggered by legitimate employee actions but executing beyond the employee's direct involvement.
Representative vendors
Nudge Security (SaaS/AI workforce governance) · Seraphic Security (browser runtime AI governance) · Certiv (endpoint runtime assurance)
PATTERN 09

Workflow Orchestration

Provides durable execution and audit trail. Is not a policy enforcement engine.

How it works
Durable workflow orchestration ensures that multi-step agent processes survive failures, maintain state, and complete reliably. Provides an audit log of workflow execution steps, state transitions, and retries. Supports human-in-the-loop gates within workflow definitions. Primarily a reliability and developer experience tool.
Enforcement point
Workflow execution state management. Workflows can include manual approval gates, but these are programmer-defined checkpoints, not real-time policy enforcement. The orchestrator executes whatever the workflow is programmed to execute.
Structural blind spot
Policy enforcement. A durable workflow can durably execute a malicious or out-of-policy action. Durability is not safety. A Temporal workflow that exfiltrates data will exfiltrate it reliably, with full state management, and produce a durable audit log of having done so. The audit trail is a record of what happened, not proof that what happened was authorized.
Attestation flaw
The workflow system's audit trail records execution state. It does not evaluate whether each step was policy-compliant. Attestation of compliance requires an external policy engine. Workflow logs are self-produced execution records.
Incident class cannot prevent
Any policy violation that is implemented as a durable workflow. The orchestration layer provides no defense. Reliable execution of malicious multi-step agent processes.
Representative vendors
Temporal (durable workflow orchestration) · Serval (agentic IT operations / process automation)
PATTERN 10
The Structural Requirement

Inline Pre-Execution Governance

Nine patterns. Nine structural blind spots. One structural requirement that all nine fail to satisfy.

Policy enforcement must happen before the tool call executes, from a position that is not the agent itself.

This requires three architectural properties that no other pattern provides simultaneously.

  • 01
    Inline position. The governance layer sits in the execution path between the agent and its tools, not adjacent to it. The tool call cannot proceed without passing through the governance layer.
  • 02
    Pre-execution evaluation. The policy decision is made before the tool executes. Allow, Deny, or Intercept. Not log, alert, and respond.
  • 03
    Independent attestation. The governance layer is a separate system from the agent. It produces its own log, with its own cryptographic integrity. The agent cannot modify the governance record. The entity that acts is not the entity that attests.

The Attestation Separation Principle is the architectural requirement that nine of the ten patterns violate. Only an inline governance proxy, positioned between agent and tool, with independent log production and cryptographic hash chaining, satisfies all three properties.

This is not a product positioning claim. It is a structural consequence of where each architecture chooses to sit in the stack.

Vendors satisfying this pattern Behavry. As of April 2026, Behavry is the only vendor whose published architecture satisfies all three properties.
Comparison

Pattern Comparison Summary

Ten patterns mapped against their enforcement point, core blind spot, and whether they can block a tool call before it executes.

# Pattern Enforcement Point Core Blind Spot Can Block Tool Call?
01LLM FirewallModel input/outputAll tool-call executionNo
02Supply ChainPre-install artifact scanPost-authorization executionNo
03Identity / JITCredential provisioningInside the access windowNo
04Observe & DetectPost-execution log analysisPrevention entirelyNo
05MCP GatewayServer/tool authorizationInside authorized connectionsPartial
06Platform-NativeWithin-platform lineageAll out-of-platform agentsPartial
07Red Team / TestingPre-deployment probingLive runtime enforcementNo
08Workforce AI Gov.Employee tool accessAutonomous agent behaviorNo
09Workflow Orch.Durable execution statePolicy enforcement entirelyNo
10Inline GovernanceTool-call execution layerNone (full coverage)Yes
Implications

Implications for Enterprise Buyers

Understanding the blind spot taxonomy produces three immediate implications for the CIOs, CTOs, and platform leaders responsible for AI deployment.

01

Ask where, not what.

Most vendor conversations are organized around capabilities: what does your tool detect? What policies can you enforce? The structurally important question is where does enforcement happen? Any tool that answers with a variation of we monitor, we detect, we alert, or we instrument is Pattern 4, regardless of how sophisticated the detection is.

02

Partial coverage compounds risk.

Combining Pattern 3 (identity) and Pattern 4 (observe-and-detect) produces a deployment story that looks comprehensive on a capability matrix and leaves the same structural gap: the tool call that executed inside the authorized window. Stacking incomplete tools does not make AI deployment safer.

03

Attestation is not a compliance feature.

The difference between a governance record and a forensic record is who produced it. An audit log produced by the governed system is self-attestation. An audit log produced by an independent, inline layer with cryptographic integrity is the only record that survives board-level scrutiny, regulatory examination, and adversarial review. If your audit comes from the agent itself, your board cannot trust it.

The EU AI Act, NIST AI RMF, and emerging enterprise procurement requirements are converging on the same question: can you prove the agent did what you say it did, from a record that the agent could not have altered? The answer determines whether an organization has governance or the appearance of governance.

Index

Company Index

Architecture classification for each of the 50 companies in this analysis, based on publicly available architectural documentation, product pages, and investor materials. Classifications reflect the vendor's primary enforcement pattern as of April 2026.

Company Architecture Notes
PATTERN 01LLM / Prompt Layer Firewall4 vendors
CalypsoAIInference platform security; red-team + guardrails at model layer
Cato NetworksSASE + AI-FW module; network-layer AI traffic control
LakeraGuard API; prompt injection / jailbreak detection; invisible to tool calls
Prompt SecurityMCP transport security; AI firewall at model I/O layer
PATTERN 02Supply Chain / Artifact Governance3 vendors
Cisco DefenseClawOpen-source RSAC 2026; scans before run; sidecar runtime plugin
CycodeAgentic development security; shift-left SDLC for AI
Koi / Palo AltoArtifact scan before install; blind post-authorization
PATTERN 03Identity / JIT Access Control10 vendors
AembitWorkload identity; secretless access; Agentic IAM with no stored secrets
Agentic FabriqAI agent identity and governance layer
Astrix Security4-method discovery + Agent Control Plane; NHI-first, JIT credentials
CyberArkPAM + AI Agent Gateway; ZSP credentials; blind inside the window
CyataAgent identity control plane; credential governance
Hush SecurityNHI + secretless access + agent identity; credential plane
KeycardAgent identity infrastructure; credential plane
Oasis SecurityPioneer NHI / AAM; JIT session identities, not tool-call layer
Ping IdentityIdentity for AI GA Mar 2026; Agent Gateway + JIT; identity plane only
SGNL (CrowdStrike)Continuous authorization; ZSP; context-aware access revocation
PATTERN 04Observe-and-Detect / Runtime Monitoring10 vendors
Acuvity / ProofpointRYNO platform; MiniProxy at transport layer; monitors, does not pre-block
AllTrue.ai / VaronisAcquired Feb 2026 by Varonis; data-centric runtime monitoring
Capsule SecurityAI agent runtime security; behavioral detection post-execution
Geordie AIObserve-and-guide; RSAC 2026 Innovation Sandbox; behavioral understanding
Knostic (Kirin)Knowledge-layer least privilege + runtime monitoring for coding agents
ManifoldEndpoint AIDR (AI Detection and Response); agent behavioral EDR
Noma SecurityDiscovery + posture + runtime protection
Portal26GenAI visibility / AI TRiSM; monitoring and audit
StraikereBPF / SDK / proxy multi-layer; MCP server is agent-invoked check
ZenityAI-SPM + runtime threat protection; low-code agent focus
PATTERN 05MCP Gateway / Access Registry6 vendors
AktoAPI security extended to MCP; transport and auth layer
JetStream SecurityAI governance blueprints; access-layer governance
MintMCPMCP hosting + gateway + monitoring
Onyx SecurityEnterprise AI agent control plane; gateway-based
RunlayerMCP server registry + SSO; governs connection, not execution
Traefik LabsTriple Gate (API / AI / MCP); TBAC enforcement; governs connection layer
PATTERN 06Platform-Native Governance6 vendors
Arkeo AIOn-premise private AI agent deployment; deployment platform, not governance
DatabricksUnity Catalog governance; self-attesting within Databricks lakehouse
Kore.aiEnterprise AI orchestration platform; in-platform governance only
MetaCompAI-governed fintech payment compliance; domain-specific platform
SanaAI knowledge platform; enterprise agent orchestration
TrueFoundryAgentic AI gateway + LLM platform; platform-scoped governance
PATTERN 07Red Team / Adversarial Testing4 vendors
Enkrypt AIAI security and compliance; red-teaming + supply chain posture
IriusRisk / ThreatModelerAI-enhanced threat modeling; design-time risk, not runtime enforcement
NoveeAI penetration testing; offensive security, not runtime governance
SPLXAI red teaming + runtime protection; adversarial testing focus
PATTERN 08Workforce AI Governance3 vendors
CertivEndpoint runtime assurance for AI tools
Nudge SecuritySaaS / AI governance; employee AI tool discovery and policy
Seraphic SecurityBrowser runtime; governs employee AI tool use in browser
PATTERN 09Workflow Orchestration2 vendors
ServalAgentic IT operations; process automation; durable execution
TemporalDurable workflow orchestration; audit trail via execution state, not policy engine
PATTERN 10Inline Governance2 vendors
AssuryMoCoP. OPA/Rego inline policy; cumulative risk graph; early stage, no attestation infrastructure
BehavryInline MCP proxy. OPA/Rego policy engine. SHA-256 hash-chained Decision Trace. Independent attestation by construction.

50 vendors. Grouped by primary architectural pattern.

Method

About This Analysis

This taxonomy was produced by Behavry Inc. based on public architectural claims, product documentation, investor materials, and technical press coverage for each vendor listed. Behavioral claims attributed to each company reflect what the company says about its own product.

Behavry's position in Pattern 10 does not reflect a commercial claim. It reflects the structural architecture of the product: an inline MCP proxy that sits between agent and tool, evaluates every tool call against OPA/Rego policy before execution, and produces a SHA-256 hash-chained Decision Trace from a system that is never the agent.

Ward Spangenberg is the Founder and CEO of Behavry Inc. and the sole inventor on 12 provisional patents (March 15, 2026 priority date) covering inline agent governance architecture.

Behavry Inc. · behavry.ai · Govern The Swarm.
Published April 2026. Updated quarterly.