Govern at the Source

The Map

The complexity of AI governance is often overstated. The attack surface is large, but the architecture required to govern it can be surprisingly small. The number of distinct controls needed is, on close inspection, fewer than the current market suggests.

A question keeps showing up in engineering Slack channels, in security team meetings, in late-night threads on Hacker News: how are you supposed to secure all this AI code? It is a good question. AI coding assistants are now the default. GitHub reported that over 46% of code written with Copilot enabled across all languages is now AI-generated.⁸ The productivity gains are real. So is the risk.

A 2023 Stanford study found that developers using AI assistants produced significantly less secure code than those without, while being more confident in its safety.¹ A 2025 Veracode report found that 45% of AI-generated code across 100+ LLMs contains security flaws.^1b Not bugs. Not style issues. Security vulnerabilities: SQL injection, hardcoded credentials, insecure deserialization, missing authentication checks. Snyk's 2024 AI Code Security Report: 56% of surveyed organizations reported AI coding tools had introduced security issues into their codebases, while only 10% had formal policies governing AI-generated code.⁹

This essay walks through the architecture. It begins with the territory, traces the shape of the threat, and arrives at a design that turns out to be relatively minimal. Parts of the analysis may prove wrong over time. The reasoning is laid out so it can be evaluated on its own terms.

The Terrain

AI is no longer just generating code. It is operating within entire organizations, autonomously, through existing channels.

Anthropic calls MCP the "USB-C for AI." The Model Context Protocol, launched in November 2024, is an open standard that solves the integration problem between AI agents and the tools they connect to. Instead of building custom connectors between every client and every tool, developers build against a single protocol. MCP servers already exist for Google Drive, Gmail, Slack, GitHub, Postgres, Stripe, Notion, Figma, Salesforce, and hundreds more. Monthly SDK downloads have reached 97 million across Python and TypeScript.

What makes MCP significant is who adopted it. OpenAI in March 2025. Google in April 2025. Microsoft integrated it into Windows 11, Copilot Studio, and VS Code. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded by Anthropic, OpenAI, and Block, with Google, Microsoft, and AWS as supporting members.

At the same time, Anthropic launched Computer Use (teaching Claude general computer skills rather than building task-specific tools), Claude Desktop's agent capabilities (autonomous multistep task execution by managing, reading, and editing files on a local machine), and the Claude Agent SDK. Foundamental coined "Outcome as a Service" in May 2024 to describe business models where providers deliver outcomes rather than tools. Gartner projects that by 2026, at least 40% of enterprise SaaS will include outcome-based pricing elements. IDC: "Process teams will design workflows around end-to-end outcomes rather than application silos, supported by a new breed of 'headless' software modules accessible via APIs and marketplaces."

AI agents connected to everything, operating autonomously, delivering outcomes through existing interfaces rather than new dashboards. The question is how to govern it.

The Agentic Org

Every one of the integrations powering the agentic org is an attack surface. The attack lives in the sequence, in the content, in the way trusted internal systems become vectors for injecting instructions into other trusted systems.

Consider a company that has gone all-in on AI agents. They have connected their agents to every system their employees touch: project management, source control, document storage, email, calendar, customer support, knowledge bases. The agents have credentials for all of these. They are reading tickets, writing emails, updating documentation, triaging support requests, scheduling meetings.

The company then defines "skills" for each agent. A skill is a discrete job function: "triage inbound support tickets," "summarize weekly engineering progress," "draft responses to customer emails," "update project status from commit messages." The agents run these skills on a schedule, across every department, dozens of times a day. What used to require a person opening an application, reading context, making a decision, and taking action is now a background process.

This is extraordinarily powerful. It is also extraordinarily dangerous. The agent that reads customer support tickets can be tricked into exfiltrating them. The agent that updates project management can be manipulated into closing tickets or injecting malicious content. The agent that sends emails on behalf of employees can be prompt-injected into sending phishing messages from legitimate internal accounts.³

The multi-hop chain

The scenario that keeps security engineers up at night. An attacker plants a prompt injection payload in a customer support ticket. The triage agent reads it, follows the injected instruction, and writes the payload into a document in the shared knowledge base. Another agent, the one that answers employee questions by searching the knowledge base, picks up the poisoned document and includes the malicious instruction in its responses. A third agent, one with write access to the project management system, receives a poisoned response and executes the embedded instruction.

The attack cascades through interconnected agents. Each amplifies the original injection because none of them were designed to distrust input from other internal systems. This is not hypothetical. Johann Rehberger showed in 2023 that Microsoft Copilot could be exploited through poisoned documents in SharePoint, causing the assistant to exfiltrate data from other connected systems without user awareness.¹⁰

This is nearly impossible to detect at the network layer. Every individual API call looks legitimate. Every agent uses its own credentials. The data flowing between systems is normal operational traffic. A gateway or proxy sees nothing wrong because nothing is wrong with any single request.

The Attack Surface

Every AI security threat lives on one of five layers, each defined by what it can see and what it can enforce. The trick is not "more controls." The trick is the right control at the layer where it has the visibility it needs.⁴

1. EndpointDeveloper / User MachineSolved

   RisksShadow AI, unauthorized tools, sensitive data pasted into prompts, browser-rendered prompt injection, unsanctioned MCP servers, data leaving via clipboard or upload.

   SeesProcesses, files, plaintext before TLS, clipboard content, application activity.

   ControlsMDM, EDR, DLP, browser-layer injection blocking, on-device inference for sensitive workflows.

   StatusMature. Existing enterprise tooling covers this entirely.

2. NetworkWire Between Endpoint and ProviderSolved

   RisksUntracked model spend, exfiltration to attacker-controlled domains, anomalous request volume, PII in outbound prompts, shadow AI calling unknown endpoints, MCP tool-call abuse.

   SeesDestination, SNI, payload size. TLS hides content unless terminated.

   ControlsDestination allowlists (Cloudflare WARP, Zscaler, Netskope), egress observability, rate limits, cost gates, outbound PII redaction, MCP threat detection.

   StatusSolved for the operational job (cost, destination, observability, PII redaction, MCP tool-call inspection). Useful, but not the primary security layer for semantic attacks.

3. CodeRepos, PRs, DependenciesSolved

   RisksAI-generated code with security flaws, prompt-injection payloads in config, hardcoded secrets, tool registrations with no confirmation, multi-hop chains baked into the codebase, RAG and memory poisoning paths, insecure output handling.

   SeesEvery line that builds the agent.

   ControlsPre-commit scan, post-commit AI code review, deterministic patterns with AI escalation, pre-deploy adversarial red team.

   StatusSolved by a combination of GitHub Advanced Security / GitLab Secret Detection, Snyk Code, Semgrep, SonarQube, and AI-aware scanners.

4. RuntimeIn-Process at Inference TimeSolved

   RisksPrompt injection at request time, output exfiltration, excessive agency, runaway tokens, untrusted retrieved content treated as instructions, hallucinated tool calls, scope creep across multi-step plans, IDOR via misused tool arguments.

   SeesThe full prompt, the full response, every tool call, the agent's plan, the user's identity.

   ControlsIn-process SDK (input sanitization, output validation, scope restriction, token budgets, tool allowlists, intent capsules, human confirmation gates), hash-chained audit logs, behavioral replay and diff.

   StatusSolved by proxilion-sdk (deterministic, <1ms decisions) and behavioral observability tooling like agent-replay.

5. Integration BoundaryOAuth Path to SaaS (Managed Agents)Solved

   RisksConfused-deputy attacks, Skill Overreach, prompt-injection payloads in Drive / Confluence / Gmail content, mass exfiltration through "summarize anything" skills, write-path damage with no human in the loop.

   SeesEvery read and every write the agent performs against your SaaS estate.

   ControlsOAuth-aware proxy, PIC authority chains, read filter, write gate, real-time action stream, one-click killswitch, policy-as-code.

   StatusSolved by Proxilion. The only piece in the stack that addresses managed agents you do not own.

Five layers. Each sees something none of the others can. A few of the threats deserve a brief gloss. Prompt injection is the original sin: an AI system treating data-plane content as control-plane instructions. Indirect prompt injection is the same attack delivered through retrieved content rather than direct user input. RAG poisoning targets the documents, databases, or knowledge bases a Retrieval-Augmented Generation system uses for context. Memory poisoning targets AI systems that persist conversation history across sessions. Excessive agency is the architectural sin: an agent granted more authority than the task requires.¹¹

One thread runs through every layer. The control that works is the one with the visibility the attack actually uses. Network proxies cannot stop semantic attacks because semantic attacks live above the network. Code scanners cannot stop runtime injection of retrieved content because that content does not exist at scan time. Runtime SDKs cannot govern agents you did not write. Integration-boundary proxies cannot scan code that never existed. The layers do not substitute for each other. They compose.

The Endpoint (Solved)

The most mature layer of AI governance is the endpoint, and existing enterprise tools apply directly. No new products needed.

MDM (Mobile Device Management) controls which applications are allowed on corporate devices. If your concern is employees using unauthorized AI tools, MDM is the answer. This extends to MCP servers: on MDM-enforced devices, you can say "you may only use these MCP servers" and maintain an updated allowlist. Enforcement happens at the device level, before any network traffic is generated.

EDR (Endpoint Detection and Response) monitors for suspicious behavior on the device itself. Unusual file access patterns, credential harvesting, data exfiltration attempts. If an AI desktop application starts behaving oddly, EDR catches it.

DLP (Data Loss Prevention) restricts what data flows into AI conversations. If an employee tries to paste customer records, financial data, or proprietary source code into a chat interface, DLP blocks it.

For organizations worried about employees pasting sensitive data into a chat window, or unauthorized AI tools running on corporate laptops, MDM, EDR, and DLP are the right answers. They are already deployed at most enterprises.

But endpoint controls have a blind spot. They govern the user's interaction with AI. They do not govern the code that AI helps write, or the agents that code creates, or the security posture of AI-integrated applications before they deploy to production. Once code leaves the developer's machine and enters source control, endpoint security has no visibility.

The Network (Useful, Not Primary)

The network has a real job to do, just not the job most products in this space are selling. Use the network for where traffic goes. Use the application layer for what it contains.

What the network layer is genuinely good at:

Destination control. Cloudflare WARP, Zscaler, Netskope, and similar zero-trust agents enforce which destinations a process is allowed to reach. If your policy says "agents may only talk to api.anthropic.com, api.openai.com, and the internal model endpoint," that policy is enforceable, inspectable, and does not require breaking TLS. Exfiltration to attacker-controlled domains becomes a connection that simply does not complete. Destination policy is the strongest control the network can offer.

Cost and budget enforcement. Model API spend is the new cloud bill, and it can grow faster than any individual engineer can track. An egress proxy that counts tokens, attributes them to teams, and enforces budgets is doing useful work. Unbounded consumption is on the OWASP LLM Top 10 for a reason.

Egress observability. Knowing which workloads call which providers, at what volume, with what latency, is genuinely useful for incident response. If a service that has never called a model API suddenly starts, the network can tell you.

Outbound PII redaction. Catching obvious PII patterns (credit cards, SSNs, known credential formats) in outbound prompts before they reach a third-party provider is a reasonable last line of defense at the egress point. It will not catch novel exfiltration, but it raises the floor on accidental leakage.

MCP tool-call inspection. Sitting between an AI coding assistant (Claude Code, Copilot, Cursor, Windsurf) and the MCP servers it talks to, a focused gateway can score every tool call against a library of threat analyzers (reconnaissance, credential theft, data exfiltration, privilege escalation, persistence) and decide allow / alert / block / terminate before the call lands. One of the rare places where in-line inspection at the wire is genuinely the right place for the control, because the protocol is bounded, the call shape is structured (JSON, not free text), and the latency budget is forgiving. proxilion-mcp¹⁷ closes this gap with 24 active threat analyzers, session correlation across multi-phase attacks, and sub-50ms P95 latency.

What now sits at the network layer

• Cloudflare WARP / Zscaler / Netskope. Zero-trust destination control. The right place for "agents may only reach these endpoints." Enforces destination policy without breaking TLS.
• proxilion-grc. Self-hosted zero-config MITM proxy focused on the operational job of the network layer: PII redaction (30+ patterns), ML-based egress anomaly detection, cost tracking with budget limits per user / provider / model, multi-tenant isolation, streaming-aware SSE redaction, and automated compliance auditing against 23+ frameworks (HIPAA, PCI-DSS, SOX, GLBA, FERPA, COPPA, CCPA, GDPR, SOC 2, ISO 27001, NIST). GraphQL API; integrates with Splunk, QRadar, ArcSight, Sentinel, Elastic.
• proxilion-mcp. Focused MCP threat-detection gateway between AI coding assistants and MCP servers. 24 analyzers, session correlation, sub-50ms P95.
• Bifrost (Maxim AI). High-performance LLM gateway with multi-provider routing, fallback, semantic caching, and policy enforcement. Strong on the cost-and-routing operational job.
• Portkey. LLM gateway with prompt management, guardrails, semantic caching, and observability.
• LiteLLM. Open-source proxy that normalizes the API across 100+ providers. The default starting point for teams that just need a unified client.
• Cloudflare AI Gateway, AWS Bedrock Guardrails, Azure AI Content Safety. The cloud-native offerings, each tightly coupled to its parent platform.

The network layer is, in 2026, a genuinely served market. The mistake to avoid is buying any of the above for a job they cannot do (content inspection of TLS-encrypted semantic attacks) when the right job (destination control, cost, MCP inspection, egress PII, compliance evidence) is what they are good at.

Now the limits. The network sees the transport layer; the dangerous attacks live in the semantic layer. TLS 1.3 hides payload content from any device not terminating the connection. To inspect content, the proxy must MITM every TLS connection, which requires a custom CA on every endpoint, breaks certificate pinning, adds latency, and concentrates every prompt and response in one decryption point that becomes the most valuable target in the environment. Even after paying all of that, the proxy sees individual API calls in isolation and cannot reason about the multi-step, multi-agent, multi-hour chains the real attacks ride on.

Rule of thumb. Use the network for where traffic goes. Use the application layer for what it contains. Do not pay TLS interception costs to learn what the endpoint and the application already know cheaper.

The network is useful, necessary, and not the primary security layer for AI. It belongs in the architecture; it does not belong in the center.

The Gaps (Now Closed)

When the first draft of this essay went up, the code layer and the runtime layer were the unsolved high-leverage gaps. Eighteen months later the field has filled in. The four controls below compose: a team running all four catches issues at the developer's keystroke, at the pull request, at the model call, and at deployment.

1. The Runtime Security SDK Solved

Application code that integrates with AI models needs runtime guardrails: input validation before prompts reach the model, output sanitization before model responses reach the user, token budget enforcement before an agent burns through your API credits, scope restrictions on agent actions before they execute something destructive, tool allowlists that bind a request to its original intent so the model cannot "decide" to call something the user never asked for.

These guardrails belong inside the application, not behind a proxy. The SDK runs in the same process as the agent, with full context, with the user's identity in hand, and with sub-millisecond latency budgets. It is a library you import, not a service you route through.

The latency point matters more than it might seem. A network proxy adds 50 to 200 milliseconds per hop, compounding across multi-step agent chains. An in-process SDK executes validation logic in microseconds. For an agent making dozens of tool calls in a single task, the difference is imperceptible overhead versus a noticeably slower product.⁷

proxilion-sdk¹⁵ is a deterministic Python SDK that imports into the application and enforces the full set of runtime controls at the call boundary:

• Deterministic, not LLM-judged. Decisions take under one millisecond and are 100% reproducible. No model in the security path, no inference cost per call, no prompt-injection-against-your-own-scanner risk.
• 14 prompt-injection patterns and 22 data-leakage patterns out of the box, covering API keys, credentials, PII, and the common injection signatures (delimiter confusion, instruction overrides, base64-encoded directives, hidden Unicode).
• Intent capsules. Every tool call is bound to the original user intent. If the model "decides" to call a tool the user never asked for, the capsule mismatches and the call is rejected. The structural fix for excessive agency.
• IDOR prevention via scope validation. The SDK checks that the user identity on the request actually owns the resource the agent is asking to read or write.
• Multi-dimensional rate limits per user, per IP, per tool, with token-bucket semantics and circuit breakers.
• Hash-chained audit logs for tamper detection, Prometheus metrics, and explainable decisions that meet California SB 53 requirements.
• Provider coverage. Works with OpenAI, Anthropic, Google, LangChain, and the Model Context Protocol.

Other reasonable choices: NVIDIA NeMo Guardrails, Guardrails AI, LLM Guard by Protect AI. The opinionated bet of proxilion-sdk is that determinism and intent capsules belong at the center; the alternatives lean more on LLM-as-judge and structural validation. The right pick depends on whether your priority is reproducibility or behavioral richness.

2. Pre-Commit (Local) and Post-Commit (PR) Scanning Solved

Before code is committed, a local scanner reads the staged diff and catches issues in the editor in milliseconds. After commit and PR open, a source-control-integrated scanner runs the full rule set with AI review in seconds. Two checkpoints, one fast and one thorough.

What a working scanner in 2026 should catch before it enters the repository:

• Provider API keys embedded in source: Anthropic sk-ant-*, OpenAI sk-*, Google AIza*, AWS access keys (AKIA*), Azure connection strings, GCP service-account JSON blobs.
• Self-issued credentials: JWT signing secrets, internal API tokens, database passwords, Redis URIs with embedded credentials, OAuth client secrets, SSH private keys, GPG private keys, .env contents.
• Webhook secrets and bearer tokens: Slack webhook URLs, Discord bot tokens, GitHub PATs, GitLab tokens, Stripe live keys, Twilio auth tokens.
• Cloud and SaaS connection strings: Snowflake account URLs with credentials, Mongo connection strings, Postgres URIs, S3 pre-signed URLs in test fixtures.
• Prompt-injection payloads in system prompts: "ignore previous instructions" patterns, role-confusion templates, delimiter confusion, hidden Unicode control characters, base64-encoded directives, prompt-leak prefixes.
• Insecure agent configurations: tool registrations with write capability and no confirmation gate, agents wired to shell execution without an allowlist, MCP server entries pointing at untrusted hosts.
• PII patterns in test fixtures and seed data.
• Dependency vulnerabilities and supply-chain risk: known-vulnerable package versions, typosquatted package names, post-install scripts that contact the network.
• RAG-poisoning paths and memory-poisoning paths: retrieval functions that concatenate user input into a system prompt without trust boundary.
• Insecure output handling: model responses piped directly into eval, exec, shell commands, SQL builders, or DOM injection points without sanitization.

• GitHub Advanced Security (Secret Scanning, Code Scanning, Dependabot). Native on github.com, on every PR, with partner-pattern feeds from the major providers so newly-leaked keys are revoked at the provider within minutes.
• GitLab Secret Detection + SAST. The same shape, native on GitLab, free at the Ultimate tier.
• Snyk Code + Snyk Open Source. DeepCode AI on the SAST side, plus the strongest dependency-vulnerability database in the field.
• Semgrep. Rule-based, open-source, scriptable. Write a custom rule for "no model API key in source" in a few lines of YAML.
• SonarQube / SonarCloud. Broad SAST coverage with the most mature on-prem story.
• Checkmarx. Enterprise SAST with explicit AI-code-review capabilities.
• TruffleHog and GitGuardian. Secret-scanning specialists that go deeper on entropy heuristics, historical scans, and revocation workflows.

Secret detection and SAST are commodities. The differentiator at the AI-specific layer is the rule set, which is why Semgrep is so useful (you can write the AI rules yourself).

3. Pre-Deployment Adversarial Red Teaming Solved

Before code deploys, an AI agent reviews the complete change set with adversarial intent. Not just pattern matching, but reasoning about how an attacker might exploit the new code, and then actually attempting the attack against a copy of the service. This is the probabilistic layer. It catches architectural risks, subtle logic flaws, and context-dependent vulnerabilities that deterministic patterns cannot express.

A concrete example. A developer adds a new endpoint that accepts a user-provided URL and fetches its content to display a preview. A deterministic scanner checks for obvious issues. But the red team agent reasons further. It considers: what if an attacker chains this endpoint with the internal agent that summarizes fetched documents? The agent could be directed to fetch a URL containing prompt injection payloads, which then propagate through the summarization pipeline. Cross-component reasoning is exactly the kind of contextual analysis deterministic patterns cannot express.

• DeepTeam by Confident AI (github.com/confident-ai/deepteam). Open-source LLM red-teaming framework with 40+ attack methods (prompt injection, jailbreaks, PII leakage, bias). Drop-in for CI.
• PyRIT by Microsoft (github.com/Azure/PyRIT). Microsoft's internal red-team framework, open-sourced. Strong on multi-turn adversarial conversations and multimodal attacks.
• Garak by NVIDIA (github.com/NVIDIA/garak). "nmap for LLMs." Probes for the long tail: hallucination, data leakage, jailbreaks, toxicity, misinformation.
• promptfoo (github.com/promptfoo/promptfoo). Eval and red-team harness focused on regression testing prompts and agents across model versions.
• Giskard (github.com/Giskard-AI/giskard). Broader ML/LLM quality framework with a dedicated LLM red-team module.

4. Agent Behavioral Observability and Replay Solved

The control that catches what the first three miss: the agent that ships clean, runs fine in eval, and then starts behaving badly in production. Hallucinated tool calls, regressions across model versions, multi-step plans that drift from user intent. None catchable in source code or pre-deployment red team; they only happen at runtime, on real inputs.

agent-replay¹⁶ is a local CLI tool that stores agent execution traces in a single SQLite file:

• Step-by-step replay. Rewind any recorded run, see exactly which step did what, which tool was called with which arguments, which retrieved document was in context.
• Diff between runs. Two traces side by side. Where did they diverge? The answer to "it worked yesterday."
• Fork and replay. Take any trace, rewind to any step, change the input or the tool response, and see what the agent would have done differently.
• AI-powered eval. Hallucination detection, safety audits, completeness checks, quality scoring, root-cause analysis. Bring your own API key.
• Guard policies. Block any delete tool call. Alert on token-usage spikes. Halt the agent if it tries to email outside the org.
• Golden datasets. Export known-good runs as a regression test suite.
• 100% local. Single SQLite file. No cloud dependency.

Adjacent commercial tooling: Langfuse, Helicone, Arize Phoenix, OpenLLMetry. The opinionated bet of agent-replay is that the debugging primitive (replay, fork, diff, guard) belongs on a developer's laptop in a SQLite file, not in a hosted dashboard.

Every row has at least one production-ready open-source option and several reasonable commercial options. The shape of the work has moved from "build the missing pieces" to "compose the right ones for your environment and operate them well."

Why Not Gateways

Gateways are useful for cost and observability. As a security architecture, they have structural limitations that matter, and they can create a false sense of security.

The current wave of AI security startups is building gateways: network-layer proxies between your application and the model provider. The pitch is compelling. "We are the firewall for AI. All your LLM traffic flows through us."

In fairness: gateways are genuinely useful for some things. Cost observability, rate limiting, usage analytics, PII redaction on outbound prompts. These are real operational problems and gateways solve them well.

As a security architecture, a gateway catches the symptom (a dangerous request) but leaves the disease (the vulnerable code that constructed it) in the repository, ready to be triggered by other vectors the gateway might not see. The team sees "gateway is active, we are protected" while the architectural flaw persists in source control, waiting for a code path that bypasses the proxy entirely.⁵

MDM already enforces MCP server allowlists

On managed devices, MDM already enforces which MCP servers are allowed. An allowlist is defined at the device level and kept updated. The gateway is solving a problem device management already solved, though edge cases in unmanaged environments may be where gateways add real value.

Agents bypass them

Modern AI agents do not make one API call. They make dozens, across multiple providers, often from different network contexts. A tool server running locally. An orchestration layer spawning sub-agents that each call different model APIs. These calls do not flow through your corporate proxy.

They are a single point of failure

When the gateway goes down, every AI feature in your application stops working. You have introduced a dependency in the critical path that has no business being there.

They have no visibility into local or self-hosted models

A growing number of organizations run inference locally using open-weight models (Llama, Mistral, Qwen) or deploy on private infrastructure. These model calls never leave the network. A gateway designed to intercept traffic between your application and a cloud provider has zero visibility. As local inference becomes more common, this blind spot will grow.

They solve the wrong problem

This is the strongest objection. A gateway scans what an application sends to a model. It does not scan the code that builds the application. The vulnerability is rarely in the API call itself. It is in the source code that constructs the prompt, handles the response, and decides what the agent is allowed to do. By the time a dangerous request reaches the gateway, the architectural mistake was made weeks ago in a pull request that nobody reviewed for AI-specific threats.

To be clear: this is not an argument against gateways existing. They serve real operational needs and a defense-in-depth approach might include both. It is an argument against gateways as the primary security control.

The Architecture

The natural place to catch AI security issues is the same place every other kind of security issue gets caught: in the code, at the pull request, before it merges.

1. Install a GitHub or GitLab app on the organization. Read-only access. No config files, no CLI tools, no agent to install.
2. Open a pull request. Pattern scanners and AI review run in parallel. Results appear as a PR comment in seconds.
3. Get notified. Critical findings go to Slack. Weekly summaries arrive by email. Issues are fixed before they merge.

The entire security workflow happens where the developer already works: in the pull request, in Slack, in email. There is no new tool to adopt. Security governance becomes a side effect of the development process they are already following.

The design principle is minimal surface area. If findings appear in the PR comment thread, developers will read them because they already read PR comments. If critical alerts go to Slack, security teams will see them because they already watch Slack. The delivery mechanism matters as much as the detection engine.

The 85/15 Thesis

Roughly 85% of AI-specific security threats have deterministic signatures. The popular belief that "you need AI to fight AI" is mostly wrong.

In practice, when detection patterns are written carefully against real codebases, roughly 85% of AI-specific security threats have deterministic signatures. Prompt injection payloads contain recognizable phrases. Hardcoded API keys match well-known patterns. Agents configured without human confirmation steps have that configuration visible in source code. These do not require AI to detect. They require well-written pattern matching, tested against thousands of examples, executing in milliseconds at zero marginal cost. The 85% number is approximate, drawn from working detection sets, not a peer-reviewed study, but the directional claim is what matters.

The remaining 15% genuinely needs AI judgment. A model API call inside an error-handling block might be fine, or it might be swallowing a critical security error. A data flow from user input to a database query might pass through a parameterized query builder (safe) or string concatenation (dangerous). For these ambiguous cases, the finding and its context get sent to an AI model for a verdict: confirm, dismiss, or escalate.

• Deterministic rules are predictable. Same input, same output, every time. No hallucinations. No prompt injection against your own security scanner.
• Deterministic rules are fast. A regex scan completes in under one second. An AI review takes 3 to 10 seconds.
• Deterministic rules are cheap. Zero API cost per pattern match. The difference between "scan everything with AI" and "scan 15% with AI" is an order of magnitude in cost.
• Deterministic rules are auditable. Every pattern can be inspected, tested, version-controlled, and explained to an auditor. "The AI said it was dangerous" is not an acceptable audit finding.⁶

The most interesting property is that the deterministic percentage should increase over time. When the AI judge confirms the same pattern 100 times with greater than 95% consistency, that pattern becomes a candidate for promotion to a deterministic rule. Critically, a human reviews and approves every promotion. Without a human-in-the-loop gate, there is a real risk of "hallucinated" security rules: patterns the AI confidently but incorrectly validated, now running deterministically on every future scan. Whether this property holds in practice at scale is an open empirical question.

The Pipeline in Practice

The harder detection problems are best understood concretely. Treat this as a worked example rather than a product description.

The scan pipeline

When a pull request is opened, the scanner receives a webhook, fetches the diff, and runs 12 scanner categories in parallel. Each scanner is a deterministic pattern matcher: regex-based rules tested against thousands of examples. The combined rule set covers prompt injection, agentic security, secret detection, PII exposure, dependency vulnerabilities, taint analysis, compliance rules, and more.²

Findings that pass a confidence threshold are finalized immediately. Ambiguous findings go to the AI judge: a single Claude API call per diff chunk that reviews the pattern match in context and returns a verdict. The response is structured JSON, not free text, so parsing is deterministic even though the judgment is not.

Agent intent analysis

Consider a PR that adds an MCP tool registration:

server.tool("send_email", { to: z.string(), body: z.string() }, async (args) => {
  await emailClient.send(args.to, args.body);  // no confirmation step
  return { sent: true };
});

An agentic scanner detects three things: a tool registration with write capabilities, an unbounded scope (any recipient, any body), and no confirmation flow. The PR comment surfaces all three with the file path, line number, and a specific remediation. This is not something traditional SAST tools look for. The vulnerability is architectural, not syntactic.

Agent replay

For multi-agent systems, the scanner traces data flow between agents in the diff. If Agent A writes to a shared resource (a database, a message queue, a file) and Agent B reads from that same resource, the scanner identifies the chain and checks whether Agent B validates its input. This is how the multi-hop injection pattern gets caught, not by intercepting network traffic, but by reading the code that builds the agents.

Breakage risk

When a PR upgrades a dependency to a new major version, a dep-analyzer checks the changelog and migration guide for breaking changes. More importantly, it performs reachability analysis: does the code actually import the APIs that changed? A major version bump in lodash that removes _.pluck is only a risk if the codebase calls _.pluck.

The self-improving loop

Every PR comment includes a feedback mechanism. When a developer reacts to a finding or replies explaining why it is a false positive, that signal is recorded against the pattern that produced it. When a pattern accumulates enough false-positive feedback, the AI judge reviews the pattern itself and either refines or suppresses it. The system's dependency on AI should decrease over time. If the underlying thesis is correct, the AI inference budget per finding should fall asymptotically toward zero as the rule corpus matures. That claim awaits longitudinal data at scale.

The Road Ahead

The architecture to govern AI does not need to be complex. The code layer needs only a small number of components, each doing one thing well.

The regulatory landscape is converging on this direction. The EU AI Act, which entered into force in August 2024, imposes specific obligations on providers and deployers of high-risk AI systems, including requirements for risk management, technical documentation, and human oversight that map directly to the code-layer controls described above.¹² In the United States, Executive Order 14110 (October 2023) directed NIST to develop frameworks for AI red-teaming and security evaluation. Organizations that build audit trails, deterministic detection, and human-in-the-loop governance into their development pipelines now will be better positioned when these requirements become enforceable standards.

The interesting open question is whether the 85/15 ratio holds as agent architectures get more sophisticated. The plausible answer is yes, since more sophisticated agents still have their behavior defined in source code, and source code patterns remain deterministic. The conclusion is not that the problem is impossibly complex. It is that the solution is surprisingly tractable once the vulnerability is located correctly. The source code. The pull request. The place where the architectural mistake is made, weeks before any gateway would see the traffic it produces.

Why the Network Layer Is Blind

"If a proxy sits between the agent and the model provider, we can see everything" is technically incorrect. The proxy sees the transport layer. The attack lives in the semantic layer.

Consider the scenario. An organization deploys AI agents communicating with model providers over HTTPS. The agents also connect to internal tools via MCP servers. Someone proposes: "Put a proxy in the middle. All traffic flows through it. Inspect everything."

TLS makes the network layer opaque

Every API call to a model provider uses TLS 1.3. A network device sitting between sees the destination IP, the SNI hostname, and the size of the encrypted payload. It does not see the prompt. It does not see the response. It sees ciphertext.

To inspect contents, the proxy must perform TLS termination. This requires:

• A custom Certificate Authority installed on every endpoint. MDM-pushed root certificates across your entire fleet. Every developer laptop, every CI runner, every production server that calls a model API.
• Breaking certificate pinning. Some AI SDKs validate that the server certificate matches an expected fingerprint. A MITM proxy's substituted certificate will fail this check.
• Introducing latency on every request. Two extra round trips per API call. For an agent making 30 tool calls in a single task, that is 60 additional round trips.
• Creating a high-value target. The proxy is now the single point where all model traffic exists in plaintext. Every prompt, every response, every API key, every customer's data flowing through agent queries, all decrypted in one place.

The security community has debated the tradeoffs of TLS interception for over a decade, and the consensus is increasingly that the risks of breaking TLS often outweigh the visibility gains.¹³

Even with MITM, the proxy cannot see what matters

Suppose you accept all the costs. You can now read every API request and response in plaintext. What do you actually see?

You see individual API calls. A prompt goes out, a response comes back. But the security-relevant context is not in any single call. It is in the application logic that constructs the prompt, interprets the response, and decides what to do next. The proxy has no access to this logic.

The proxy sees the transport layer. The attack lives in the semantic layer. A prompt injection payload embedded in a retrieved document looks identical to a legitimate document. The model's response containing exfiltrated data looks identical to a normal summary. Both are valid JSON responses with plausible text content.

The multi-hop problem compounds this

In the multi-hop chain described earlier, the attack spans multiple agents, multiple API calls, and potentially multiple hours. The proxy sees each API call in isolation. It has no concept of a "chain." To detect the chain, the proxy would need to:

• Parse and understand the semantic content of every request and response.
• Maintain a stateful graph of all data flows between agents across time.
• Reason about whether a particular response is the model following legitimate instructions or following injected instructions embedded in retrieved content.

At that point, the proxy is not a network device. It is an AI security product that happens to run on the network. And it is running at a massive disadvantage compared to the same logic running at the application layer, because it lacks the application context.

The endpoint and application layer see everything the proxy wants to see

The endpoint layer already provides the visibility a network proxy claims to offer, without requiring TLS interception. MDM controls which AI applications and MCP servers are installed. EDR monitors process behavior at the OS level, before encryption. DLP inspects content at the application boundary, where data is still plaintext. Cloudflare WARP enforces Zero Trust network policies without inspecting the encrypted payload.

The application layer (runtime SDK) provides the deep visibility neither the proxy nor the endpoint can offer. The SDK runs inside the application process. It sees the complete prompt before serialization. It sees the complete response after deserialization. It sees every tool call with its full parameter set. It knows which agent is executing, what task it is performing, what tools it has access to, and what scope restrictions should apply.

A concrete attack trace

An attacker submits a customer support ticket containing a prompt injection payload hidden in a Unicode-encoded string. The payload instructs any agent that reads it to include the contents of environment variables in its next response.

The proxy never had a chance. At no point in this attack did a single network request look anomalous. The attack was semantic. The endpoint caught nothing because the attack did not involve unauthorized applications or data patterns DLP is trained to recognize. Only the application layer had enough context to detect and prevent the attack.

The Cloudflare WARP argument

Organizations using Cloudflare WARP or similar Zero Trust network agents already have network-level governance without a dedicated AI proxy. WARP enforces DNS filtering, destination allowlists, and device posture checks at the endpoint. If your policy says "agents may only communicate with api.anthropic.com, api.openai.com, and your internal model endpoint," WARP enforces that. No exfiltration to attacker-controlled domains. No unauthorized model providers. This is the network-layer control that actually matters: controlling where traffic goes, not trying to inspect what it contains.

The Managed Agent Problem

Everything argued so far assumes the organization owns the code. That assumption is breaking. The industry is moving toward fully managed agents, where nobody on your team wrote the agent code.

Anthropic now offers managed Claude agents that organizations deploy through a console, not a codebase. The agent runs on Anthropic's infrastructure, connects to your systems through OAuth, and executes tasks defined through a configuration interface. You never see the orchestration code. You never import an SDK. The agent is a service, not a dependency.

Platforms like OpenClaw take this further. An organization connects Google Drive, Confluence, Slack, Jira, Salesforce, GitHub, email, and calendar through OAuth. An administrator defines "skills" for each department: triage inbound support tickets, draft weekly engineering summaries, reconcile expense reports, schedule candidate interviews. The agents execute these autonomously, reading from and writing to every connected system, dozens of times per day.

The agentic org from earlier, but with one critical difference: nobody wrote the agent code. There is no repository. There is no pull request. There is no diff to scan.

What you lose

The entire code layer becomes inaccessible. There is no runtime SDK to embed in an agent the team did not build. There is no PR to scan. There is no source code to red-team. The four components described above as the solution to AI governance all require one thing the managed agent model does not give: the code.

What you are left with

• Audit logs. The platform records which actions the agent took. You can query them, pipe them into your SIEM, set up alerts. But you are reading a log of what already happened. The damage is done by the time your alert fires.
• SIEM correlation. Detections that correlate agent actions across systems: "Agent read 500 customer records in 10 minutes." Valuable signals, but by definition after-the-fact.
• Platform-provided guardrails. Configuration options to restrict which tools the agent can call, require human approval for certain action types. You cannot verify that the guardrail works. You cannot test it adversarially. You are delegating your security posture to a vendor's checkbox.

This is the honest gap. The argument was that prevention beats detection. The argument was that the vulnerability lives in the code. Both claims hold up, and both are irrelevant when the code is not yours.

The concrete scenario

An organization has connected Google Drive, Confluence, Slack, and email to a managed agent platform, with skills defined for every department.

The multi-hop chain plays out identically, except now you have no runtime SDK intercepting the poisoned input, no pre-commit scan that caught the vulnerable data flow, no code-level control at all. Your SIEM might flag the anomaly. Eventually. If you built the right detection. This is logging. It is not prevention.

What actually needs to exist

The answer is not to reject managed agents. The productivity gains are too real and the adoption curve is too steep. But the industry needs a governance layer for agents nobody on your team wrote.

• An integration-layer proxy with semantic awareness. Not a dumb MITM that breaks TLS to inspect ciphertext. A proxy at the OAuth boundary, between the managed agent platform and your connected systems. When the agent requests access to Google Drive, the proxy evaluates the request against a policy engine: which documents can this skill access? What fields can it read? Can it write, or only read? Authorization-layer enforcement, not network-layer inspection.
• Write-path confirmation gates. Any action that modifies state (sending an email, editing a document, posting a Slack message, closing a ticket, updating a CRM record) should require explicit confirmation through a policy the organization controls, not one the platform provides.
• Content-boundary enforcement on reads. When the managed agent reads from your systems, a lightweight content filter at the integration boundary scans for known injection patterns before the content reaches the agent. Not foolproof, but catches the known attack signatures.
• Real-time action streaming, not just logs. A log tells you what happened. A stream tells you what is happening, and lets you kill it. Managed agent platforms should expose a real-time event stream with sub-second latency, not a batch log that updates every five minutes.

When the first draft of this essay went up, none of the above existed in deployable form. The security vendors were busy intercepting model-API traffic, which is the wrong layer. The gap sat exactly at the integration boundary: the OAuth connections between the managed agent and the systems it operates on.

So I built it. Proxilion¹⁴. Self-hosted, MIT-licensed, no telemetry, no SaaS, no upsell. The repo is on GitHub. The OAuth integration boundary is the single preventative chokepoint left for governing managed agents you do not own, and prevention-by-construction is still possible there.

What Proxilion actually does

Proxilion is an OAuth-aware reverse proxy that interposes itself between the managed agent platform and the SaaS systems it operates on (Google Drive, Gmail, Calendar at launch; Salesforce, Jira, Notion in a few hundred lines of adapter code per upstream). It swaps in its own bearer token at the OAuth handshake and stays in path for every subsequent request. Four things happen at that chokepoint:

• Read-filtering for prompt injection. Response bodies from Drive, Gmail, and the other upstreams are scanned for known injection patterns (delimiter confusion, hidden Unicode, base64-encoded directives, "ignore prior instructions") and stripped or quarantined before the agent ever reads them. The poisoned Confluence page from the attack scenario does not reach the agent's context window; the payload is excised in transit.
• Write-gating with a real human in the loop. External email sends, mass deletes, external file shares, and other state-changing actions are blocked until a person explicitly approves through Slack or a ticket. Configurable per sender, per domain, per operation. The approval flow lives in your infrastructure, not the platform's.
• Real-time action stream and one-click killswitch. Every agent action streams to an operator dashboard and your SIEM the moment it happens. One click revokes every capability tied to that agent or user within one request cycle. The difference between forensics and prevention.
• YAML policy engine with hot reload. Rules like "this agent can read engineering docs but never finance" compile into a match-expression engine and reload without restarting. Policy-as-code, evaluated at the boundary.

The deeper move: authority chains, not just policy

Every action that traverses Proxilion is bound to a cryptographic authority chain rooted at the specific human the agent is acting for at that moment. The primitive is PIC (Provenance, Identity, Continuity), a protocol by Nicola Gallo that formalizes what an OAuth token is missing. Three invariants:

• Provenance. Every action traces back to an immutable origin principal p₀: a real human, identified at a real moment, through a real auth flow. The chain is signed at each hop. You can prove, years later, that this exact action was authorized by this exact human.
• Identity. The origin identity cannot mutate across hops. The agent cannot "become" a different user mid-chain. The skill cannot launder authority from one principal into actions performed under another. Identity is set at p₀ and frozen.
• Continuity. Authority can only shrink along the chain, never broaden. Each hop is a Proof of Causal Authority (PCA) whose granted operations are a strict subset of the prior hop's. The intern starts with the intern's permissions and ends with no more.

This is what closes the confused deputy gap that nothing else in the stack closes. A managed agent acting on Alice's behalf is the textbook confused deputy: it holds the OAuth scope of the tenant (broad) while being asked to act with Alice's authority (narrow), and absolutely nothing in the platform forces the narrowing. PIC forces it, mathematically. Proxilion is the runtime enforcement of that primitive on the OAuth path.

Skill Overreach, by construction

This solves what the platforms have started calling the Skill Overreach problem. You train one agent for the whole org, attach it to Drive, Gmail, Salesforce, Jira, Notion, and hand it out to every employee. That single agent now holds the union of every permission any of its users have. You have deployed a super-user wearing a friendly avatar. The OAuth scope says drive.readonly for the tenant; the skill says "summarize anything the user asks about"; the runtime has no idea whether the human on the other end is an intern, a finance lead, or the CEO.

Proxilion forces the skilled agent back into the specific human user's box. The intern's request to "summarize Q3 financials" fails the same way it would if the intern opened Drive directly. The CEO's request succeeds. The skill stays the same; the authority is no longer the skill's, it is the user's. Prevention by construction, even when the skill itself is overpowered, even when prompt injection lands.

What it costs you

Proxilion in its in-path mode terminates TLS inside your perimeter. That visibility (plaintext request and response bodies) is what enables read-filtering and write-gating; it is also why the proxy MUST run on your infrastructure. CAT signing keys and plaintext SaaS payloads do not belong on someone else's machines, including ours. There is no hosted Proxilion. Two additional modes (pre-flight advisor and audit-only ingestion) exist for platforms that do not let you sit in path; they trade enforcement strength for deployment flexibility.

There is a ceiling Proxilion cannot break alone: cryptographic enforcement at the SaaS provider itself. That requires SaaS-side adoption of PIC, an RFC 8693-shaped token exchange where Drive, Gmail, and the rest validate the chain before acting. Until that lands, Proxilion gives the strongest enforcement possible without SaaS cooperation, and is upfront about the gap.

The fit with the rest of the stack

For self-hosted agents, source code analysis remains the right approach: the runtime SDK, the pre-commit scanner, the AI code review, the red team. For managed agents, source code analysis cannot govern an agent that has no source code, and integration-boundary enforcement with cryptographic authority binding is what fills in. Same essay, two halves of the same architecture. One sits in your repo; the other sits in your OAuth flow.

Putting It All Together

AI governance is not one product. It is a set of small focused controls, each placed at the exact layer where it has the visibility it needs.

The list below is grouped by attack surface, top to bottom, in roughly the order an attack would travel. None of these layers is sufficient on its own; none of any two is redundant. Most organizations need only three or four; the right three or four depend on which surfaces actually exist in your environment.

1. The Endpoint User & Device

   RisksShadow AI, unauthorized tools, sensitive data pasted into prompts, hidden prompt injection in browser-rendered content, data leakage to public model providers.

   ControlsMDM app allowlists, EDR behavior monitoring, DLP outbound inspection, browser-layer injection blocking, private on-device inference for sensitive workflows.

2. The Code Layer Source & PRs

   RisksAI-generated code with security flaws, prompt-injection payloads checked into config, hardcoded secrets, agent tool registrations with no confirmation step, multi-hop injection chains baked into the code itself.

   ControlsPre-commit scans, post-commit AI code review on every PR, deterministic pattern matching with AI-judged escalation, pre-deploy adversarial red-team review, living spec-to-code pipelines.

3. The Runtime In-Process SDK

   RisksPrompt injection at request time, output exfiltration, agents acting outside their intended scope, runaway token spend, untrusted retrieved content treated as instructions, IDOR via misused tool arguments.

   ControlsIn-process guardrails (input sanitization, output validation, scope restriction, token budgets, tool allowlists, intent capsules, human confirmation gates), deterministic sub-millisecond decisions, hash-chained audit logs. Reference implementation: proxilion-sdk. Alternatives: NVIDIA NeMo Guardrails, Guardrails AI, Protect AI's LLM Guard.

4. The Agent Behavior & Replay

   RisksNon-reproducible failures, regressions between model versions, hallucinated tool calls, multi-step plans drifting from user intent, golden-path regressions that only show up under real traffic.

   ControlsLocal time-travel debugging of agent traces, fork-and-replay to test fixes, AI-powered evaluation loops, behavioral diffs across runs, guard policies as a kill switch, golden-dataset regression tests. agent-replay is the local-first reference; Langfuse, Helicone, Arize Phoenix, OpenLLMetry cover the same surface with hosted-vs-self-hosted trade-offs.

5. MCP & Tools Tool-call Layer

   RisksRogue or compromised MCP servers, tool calls from compromised accounts, insider misuse via coding assistants, tool registrations with write access and no confirmation, MCP responses carrying injection payloads upstream.

   ControlsMCP server allowlists (enforced by MDM on managed devices), tool-call threat detection in real time, per-tool policy with hot reload, behavioral analysis of who is calling what and when.

6. The Integration Boundary Managed Agents

   RisksConfused-deputy attacks (the OAuth token does not carry which user the agent is acting for), Skill Overreach (one agent holding the union of every user's permissions), prompt-injection payloads in Drive / Confluence / Gmail content, mass exfiltration through "summarize anything" skills, write-path damage with no human in the loop, authority laundering between hops in a multi-agent chain.

   ControlsOAuth-layer interception with PIC authority chains rooted at the human user, read-path injection filtering, write-path human approval gates per sender / domain / op, real-time action stream with a one-click killswitch, policy-as-code with hot reload. Proxilion is the self-hosted, MIT-licensed reference implementation.

7. Identity & Tokens Auth Surface

   RisksLeaked bearer tokens replayed from anywhere on the internet, agents exchanging tokens across boundaries with no proof of possession, long-lived API keys with broad scopes.

   ControlsProof-of-possession tokens, IP validation, TOTP, certificate-bound credentials, short-lived narrowly scoped tokens.

8. The Network Cost, Egress & MCP

   RisksUntracked model spend, PII flowing out in prompts, anomalous traffic patterns, exfiltration to attacker-controlled domains, MCP tool-call abuse. Not the primary security layer for semantic attacks but solved for the operational job.

   ControlsDestination allowlists (Cloudflare WARP, Zscaler, Netskope), outbound PII redaction and compliance auditing via proxilion-grc, MCP threat inspection via proxilion-mcp, LLM gateways for cost and routing (Bifrost, Portkey, LiteLLM), SIEM forwarding.

9. Cloud & Data Workspace Posture

   RisksMisconfigured cloud surfaces accessible to agents, oversharing in Google Workspace that becomes a feast for the Q&A agent, Shadow IT, data classification drift, PII sitting in places it should not.

   ControlsAgentless CSPM / DSPM / CIEM / ASM with deterministic policy, workspace-level DLP and Shadow IT discovery, NIST CSF / SOC2 / HIPAA / GDPR evidence aggregation, automated compliance reporting.

10. Governance & Evidence Policy & Compliance

    RisksEU AI Act and NIST AI RMF obligations with no audit trail, model registry drift, AI usage without policy-as-code, manual compliance attestation that lags reality by months.

    ControlsAI policy-as-code with real-time enforcement, unified model registry, token-based access control, OSCAL-native evidence collection across platforms, NIST CSF 2.0 control mapping with a living dashboard.

11. Physical-World Agents Bio & Robotics

    RisksAI-controlled labs and robots taking destructive physical actions on hallucinated or injected commands; synthesis requests for dangerous DNA, peptides, or chemicals; physical-invariant violation (speed, torque, geometry).

    ControlsDeterministic, fail-closed cryptographic firewalls in front of physical actuators; signed command validation; authority-chain narrowing; biological and physical invariant screening; tamper-proof auditing.

12. Data & Reproducibility Inputs to AI

    RisksTraining data and scientific datasets that are not FAIR (findable, accessible, interoperable, reusable), un-reproducible model runs, hallucinated world state in long-running simulations.

    ControlsPre-flight dataset validation against FAIR principles, persistent fact stores for simulations, hardware and software stack diagnostics with AI log analysis.

Read top-to-bottom, the list tells a single story: AI governance is a set of small focused controls, each placed at the exact layer where it has the visibility it needs. The endpoint catches what the endpoint can see. The code layer catches what only the code can see. The runtime catches what only the running process can see. The integration boundary catches what only OAuth-aware infrastructure can see. Stack them and the surface is covered.

What this looks like in practice

An organization adopting this model from scratch does not need to deploy all twelve layers at once. A reasonable rollout starts where the blast radius is widest and works inward.

Begin with the endpoint and the code layer. MDM allowlists, browser-layer injection blocking, and private on-device inference put a floor under endpoint risk in days, not quarters. AI-aware pre-commit scanning and PR-time review put a safety net under every line of AI-assisted code without changing how developers work.

Then move into the runtime: in-process guardrails on the AI-integrated services your organization already runs, with deterministic rules in front of probabilistic inference, and observability that treats the agent as a first-class system you can replay, diff, and evaluate after the fact.

If managed agents are in use, the integration boundary is the highest-leverage single investment in the entire program. It is the only layer that turns a super-user agent into a governed user by construction, regardless of which model is running or which platform is hosting it.

Finally, convert the controls already in place into compliance evidence. Policy-as-code, unified model registries, and OSCAL-native evidence aggregation make the EU AI Act and NIST AI RMF stop being a quarterly fire drill and start being a side effect of how the organization already ships.

A note on the spirit of this

The early internet was full of pages like this. Pages where someone laid out everything they knew on a topic, with all the parts named, the architecture diagrammed, no upsell, no signup wall. You read one and walked away with a complete mental model and a list of things to try.

That is the goal here. AI governance is sometimes framed as a thicket so tangled that you need a vendor with a glossy deck and a pricing page that starts at "contact us" to find your way through. It is not a thicket. It is a small number of attack surfaces, a small number of controls, and a clear story about which layer sees what.

The work is to pick the layers that match your organization, build or buy what fits, and ignore the rest. Proxilion is one of the pieces, free and MIT, for the layer nobody else is building yet. The rest are already on your laptop, in your CI, or one quarter away from being in your CI. For the first time in years, the defense is keeping pace with the capability. The concepts exist. They are simple. They are good. Go use them.