Introducing OBEL Developer: Governance for the CLI Layer

When organisations deploy an AI governance platform, they typically think about the chat interface. The web application employees use to interact with AI models. The gateway that scrubs prompts, classifies content, and produces an audit log. That layer is necessary. It is also only half the picture.

The other half is the CLI layer. AI coding agents — Claude Code, Aider, Gemini CLI, Goose, and a growing ecosystem of SDK-based tools — operate entirely outside every web-based governance layer. They hit provider APIs directly. They carry codebases, architecture documents, internal tooling, environment configurations, and proprietary logic through those connections with no scrubbing, no classification, no audit log, and no visibility for the organisation that owns the IP being discussed. Developers are, by some distance, the highest-risk AI users in a technology organisation. They are also, consistently, the least governed.

Today we are changing that. OBEL Developer is a new product tier built specifically for this problem. It puts the full OBEL governance stack into the request path of every supported developer AI tool. Every session. Every prompt. Every response.

The governance gap nobody was filling

When a developer runs an AI coding agent against a production codebase, the content that reaches the provider API can include source code from proprietary systems, API keys and secrets present in configuration files, architectural context that represents years of accumulated IP, business logic that competitors would pay for, and data structures that reveal how sensitive information is stored and processed. None of this is logged at the organisation level. None of it is scrubbed. None of it is classified. The developer's intent is almost always legitimate. The exposure is real regardless.

The same gap exists across the full developer tool ecosystem. Aider routes through OpenAI, Anthropic, or Mistral depending on configuration. Gemini CLI routes through the Google Generative AI API. Goose, OpenAI Codex CLI, and every internal tool built on an LLM SDK adds to the same unaudited surface. Most security and IT teams are unaware of the volume of traffic through these channels, let alone its content.

Supported tools

OBEL Developer ships with three proxy endpoints covering the major developer AI API formats:

• Anthropic proxy (/api/proxy/anthropic): Claude Code, any Anthropic SDK client. GA. Two env vars: ANTHROPIC_BASE_URL and ANTHROPIC_API_KEY.
• OpenAI-compatible proxy (/api/proxy/openai): Aider, OpenAI Codex CLI, Goose, and any tool that respects OPENAI_BASE_URL / OPENAI_API_KEY. Beta. Routes to OpenAI, Mistral, DeepSeek, Groq, or xAI based on the model name.
• Gemini proxy (/api/proxy/google): Gemini CLI and any tool using the Google Generative AI REST API. Beta. Auth via GEMINI_API_KEY passed as the x-goog-api-key header.

The OpenAI-compatible proxy is the most broadly applicable. Aider, Goose, and Codex CLI all respect OPENAI_BASE_URL — a single configuration change governs all three simultaneously, across every model they support. Aider users running Claude Sonnet 4.6 via the Anthropic backend should use the Anthropic proxy instead, which Aider also supports natively via --anthropic-api-base.

How the proxies work

Each proxy operates as a transparent pass-through between the developer's tooling and the upstream provider. The developer points their tool at the OBEL proxy endpoint and authenticates with their OBEL API key. OBEL resolves the org's real provider API key from the vault and uses it for the upstream call. The developer's experience is identical to calling the provider directly — same models, same responses, same latency profile — with governance applied invisibly in the path.

At the proxy layer, every request — regardless of tool or provider — passes through the full OBEL governance stack before reaching the upstream API:

• PII scrubbing: personal data detected and redacted before the prompt leaves your network
• Prompt injection detection: five built-in rules covering ignore-previous-instructions attacks, role-reversal attempts, system override patterns, jailbreak sequences, and indirect tool injection
• System prompt enrichment: policy context prepended or appended to every developer session based on your org's Dev Policy Packs
• Repo attribution: git remote and working directory extracted from the session context and recorded against every audit log entry
• Audit logging: every request logged with model, token counts, cost, repo, and developer identity

After the response returns from the upstream provider, OBEL runs a second pass:

• OWASP Top 10 code scanning: LLM-generated code blocks scanned for injection vulnerabilities, insecure deserialization, hardcoded secrets, path traversal, and other OWASP categories before the response is returned to the developer
• Security event recording: injection attempts and code security findings written to the security events log with severity classification

The entire pipeline adds sub-100ms latency in the median case. For the developer it is invisible. For the organisation it produces a complete, structured record of every AI coding session.

Dev Policy Packs

OBEL Developer ships with a library of built-in Dev Policy Packs, configurable per organisation. Each pack is a set of rules applied at a specific point in the request pipeline.

Injection Detection packs

Extend the five built-in injection rules with organisation-specific patterns. If your environment has seen specific attack patterns in penetration tests or red team exercises, they can be encoded as custom rules and applied to every developer session.

Code Security packs

OWASP-aligned rule sets covering the categories most relevant to your stack. The default pack covers the OWASP LLM Top 10 categories for generated code. Language-specific packs are available for Python, TypeScript, Go, Java, and Rust. Enterprise packs can encode your organisation's internal secure coding standards.

Enrichment packs

Policy context injected into every developer session. Secure coding baseline rules. Internal API usage guidelines. Data handling requirements. The enrichment pack makes policy enforceable at the inference layer, not just in a document on a shared drive. It does not change what the developer asks. It shapes how the model responds.

Attribution packs

Repo attribution configuration for your git remote naming conventions. OBEL parses the session context to extract the active repository and working directory. Attribution packs allow you to define how that context maps to your internal project taxonomy for spend reporting and analytics.

Per-repo analytics: the question security teams have never been able to answer

With repo attribution in place, OBEL Developer surfaces a view that has not previously existed: which projects are consuming the most AI tokens, which developers are the highest spenders, and where injection attempts are occurring. This is not a vanity dashboard. It answers questions that matter.

Which repositories are generating the most AI traffic? That tells you where your highest IP exposure is concentrated. Which developers have the highest injection hit rates? That tells you which accounts warrant a conversation. Which projects have the most OWASP findings in their AI-generated code? That tells you where your code review process needs extra scrutiny. The analytics layer turns a governance function into an operational intelligence function.

Why this is different from enterprise chat plans

Claude Enterprise provides data privacy guarantees and organisational management for Claude.ai usage. ChatGPT Enterprise does the same for chatgpt.com. Google Workspace AI covers the Gemini web interface. None of them govern the API. Claude Code, Aider, Gemini CLI, and any SDK-based tool call the API directly. The governance those products provide stops at the browser. OBEL Developer starts where the browser ends.

OBEL Developer is not a replacement for Claude Enterprise or any enterprise chat plan. It governs the surface those products cannot reach: the API path used by CLI tools, SDK integrations, CI/CD pipelines, and internal tooling. For organisations that have both, they are complementary — the chat interface is covered by the enterprise plan, the API layer is covered by OBEL.

Pricing: seat fee only, zero usage included

OBEL Developer is $29 per seat per month. The seat fee covers the governance infrastructure: the proxy, the policy packs, the audit logging, the analytics. It does not include token usage. Developer AI token consumption is inherently variable and can be substantial. We do not think it is reasonable to bake that risk into a flat seat fee and hope the averages work out.

Token usage is priced separately: bring your own Anthropic API key (the proxy passes your key through) or use an OBEL prepay pack with a 20% markup. BYOK is the right choice for organisations that already have Anthropic contracts. The OBEL pack is the right choice for teams that want consolidated billing.

Organisations that need both Developer governance and full AI workspace capabilities can combine OBEL Developer with a Standard or Premium tier. The Developer tier is an additive seat fee on top of the base platform, not a separate product requiring a separate deployment.

Available now

OBEL Developer is available today for all self-serve signups. Existing organisations can add Developer seats from the billing settings in their OBEL dashboard. Configuration is a two-step process: add the proxy endpoint to your environment, install the org API key, done.

For organisations with existing Claude Enterprise agreements or bespoke Anthropic contracts, reach out to discuss how OBEL Developer fits alongside your current arrangements. The proxy is compatible with any Anthropic API configuration.