AI Agent Governance: Build vs. Buy

Do you build a governance layer yourself, or do you buy one? Both paths are viable, with different trade-offs. This is a framework for thinking through which one fits your organization.

What you're actually building

Before the build vs. buy decision makes sense, you need to know what "agent governance" requires. It is a production control system, not a library.

A complete agent governance layer requires:

• Intercept proxy: A network proxy that sits between agents and the LLM API, capable of reading and parsing every response, identifying tool calls, and making allow/deny decisions.
• Deny-list engine: Pattern-matching system with threat categories (SQL injection, filesystem traversal, privilege escalation, data exfiltration, malicious external calls), each with regex patterns, OWASP updates, and version control.
• Policy management: A language for expressing allow and deny decisions, which a security team can read and modify without framework expertise.
• Agent identity registry: Know which agent is making which request. Bind agents to policies. Update policies without redeploying agent code.
• An audit trail the agent cannot reach: each decision logged with timestamp, agent identity, action attempted, policy evaluated and verdict, outside the agent process.
• Investigation workflows: SOC team tools for triaging ambiguous actions, reviewing denied requests, and refining policy based on what agents are actually trying to do.
• Alerting integration: Webhooks to Slack, PagerDuty, or your existing security stack.
• Compliance exports: SOC2 and ISO 27001 auditors want to see evidence of control. Governance systems need to produce audit reports with findings, remediations, and policy trails.

That's eight major components, each with operational dependencies. The complexity compounds when you add support for multiple LLM APIs (Claude, OpenAI, open-source via compatible endpoints), multiple deployment models (cloud-hosted vs. VPC), and multiple agent frameworks (Anthropic SDK, LangChain, etc.).

The build path

Timeline: we do not know what this costs you, and a month range with nothing behind it is worse than no range. What we can tell you is what it has cost here: a deny list of 111 compiled rules at commit 87ccd47, 3,802 proxy test cases and 448 more at the repository level, kept current against a provider API that moves.

Advantages of building: You own the entire system. No vendor lock-in. You can customize the policy language for your unique agent architectures. You control the audit log schema and compliance export format. You can optimize for your specific LLM API usage patterns.

Disadvantages of building: You own the entire system. Engineering time diverted from your core product. Threat patterns require ongoing maintenance: OWASP revises its agentic threat document, and the edition we read, v1.1, lists seventeen categories. Every new vulnerability class (prompt injection variants, tool parameter manipulation, agent state manipulation) requires pattern updates, testing, and deployment. You'll need to hire security engineers to manage this. And an auditor will ask how you know the log has not been edited, which is a question about the write path, not about the dashboard.

The buy path

Timeline: you point your agents at a different endpoint, which is one line of configuration. Nobody has done it in production yet, so treat the deployment time as unproven.

Advantages of buying: you get the rules and the tests without writing them. Here, the patterns are maintained by one person, in public, with the suites and the threat corpus run in CI on every push. There is no evidence package and no SOC 2 report. There is a queryable, hash-chained log, and no latency figure: nothing in the repository measures governed-request latency, and a streamed response is buffered in full before it is judged.

Disadvantages of buying: Vendor dependency. If the platform goes down, your governance layer goes down. Less customization of policy logic compared to building your own DSL. You're constrained by the platform's API integration library: if they don't support a tool type you need, you have to wait for them to add it or work around it.

The decision framework

The comparison, one line each.

• Time to production: Build: we will not invent a range for you. Buy: one line of configuration, and nobody has run it in production yet.
• Maintenance overhead: Build: ongoing engineering team, threat pattern updates, security patches. Buy: managed service, updates included.
• Compliance readiness: Build: you build the evidence. Buy: whatever that vendor holds. Ours holds none.
• Customization: Build: unlimited. Buy: configurable within platform constraints.
• Threat pattern currency: Build: manual updates, lag time between OWASP publication and your deployment. Buy: the vendor's cadence, which here is one person's.
• Total cost of ownership: Build: engineering salary × months + ongoing security headcount. Buy: per-agent subscription.
• Organizational risk: Build: if the people who wrote it leave, the system is orphaned. Buy: you take vendor risk instead, and with Intercis today that vendor is one person.

Build favours a large engineering team, a compliance requirement no vendor meets, and the ability to absorb the delay while agents are already running.

What to ask a vendor

The six questions worth asking are on what agent governance is, each one answered for Intercis, including the two we lose.

How to decide

The question under "build or buy" is how long you can wait and what team you have.

If you have agents in production today, building the layer first is a bet against a provider API that moves underneath you.

If your agents are further out, you have room to run the analysis, prototype in-house and evaluate vendors in parallel. The build path can be the right one.

What you shouldn't do: wait until the agents are in production and then realize you need governance. That's how you end up in emergency mode, running agents without controls, and then rushing to build or buy something you didn't plan for.