Custos: A Security Gateway for Governing AI Agents Through Policies and Approvals

AI agents are becoming a powerful way for enterprises to interact with internal systems. As these agents gain access to more tools and APIs, a core challenge emerges: how can organizations control what they can access, what they're allowed to do, and how those actions are tracked? Custos was built to solve exactly this problem — it sits between AI agents and the tools they invoke, serving as a security and governance gateway that provides centralized identity verification, access policies, approvals, and auditability.

Inserting a Governance Layer Between AI and Tools

The traditional approach leaves access control decisions to the underlying applications themselves. But as the number of agents and callable tools multiplies, this decentralized model quickly becomes unmanageable. Custos's core idea is to insert an independent governance layer between AI agents and enterprise tools, centralizing the decision of "can this tool be called" into a single control plane.

From Custos's dashboard, teams can centrally manage tools, policies, audit events, and other security controls. This means the security model no longer depends on each application's own implementation — instead, there's a single entry point for cross-cutting visibility and control.

Automatically Discovering Tools via OpenAPI Specs

In a demo, Custos connects to an Orders API. Instead of manually defining each operation, you simply provide the service's OpenAPI specification. Custos reads the spec and understands the tools the service exposes.

Once the spec is processed, the system confirms that the connection has been successfully discovered and lists the tools available for that service — such as the get_order operation in the example. This spec-driven auto-discovery dramatically reduces onboarding friction: the gateway recognizes whatever capabilities the service exposes, with no risk of omissions or manual maintenance errors.

That said, discovering a tool is not the same as authorizing its use. This is a key design distinction in Custos — just because an API exposes a tool doesn't mean it's usable. That decision belongs to policy.

OpenAPI (formerly known as Swagger) is a standard format for describing RESTful APIs, listing all endpoints, request parameters, response structures, and authentication methods in a JSON or YAML file. It has become the industry standard for API documentation and interoperability, and most modern backend frameworks support auto-generating OpenAPI spec files. For gateway products like Custos, an OpenAPI spec is a natural "tool catalog" — a single machine-readable file that automatically enumerates all operations a service exposes, with no need to enter them manually. This makes onboarding new services nearly zero-configuration, and updates to spec files can be automatically reflected in the gateway's tool list, reducing the lag and error risk of manual maintenance.

Policy Enforcement: Who Can Do What, and Under What Conditions

Once tools are discovered, the next step is configuring policies for the Orders service. In the demo, a policy called "read orders" is created, and the tools it governs are selected. You can precisely define which operations are permitted, who can access them, and under what conditions. In this example, the get_order operation is explicitly allowed.

This reflects Custos's governance philosophy: access is governed by policy, not left entirely to each underlying application. Once configured, teams can review conditions and publish the policy — at which point Custos has a clear set of rules for how that tool may be accessed.

It's worth emphasizing that Custos isn't simply a transparent proxy forwarding traffic. It evaluates every request against pre-defined policies, giving teams a centralized place to control AI tool access. The gateway isn't a pass-through — it's a decision-maker with built-in judgment.

Auditability: Recording the Context Behind Every Action

Governance isn't just about blocking — it's about traceability. Through audit events, Custos provides detailed information about each event, including the request context and the security decisions associated with it.

This creates a traceable activity history inside the gateway. Teams don't just know "an API was called" — they can see exactly what happened around that call: the request source, the basis for the decision, and why it was allowed or denied. For compliance audits and post-incident investigations, this level of visibility is essential.

In AI agent security, auditability often matters more than in traditional software systems. This is because AI agent decision-making carries a degree of opacity — the same input in different contexts can trigger entirely different sequences of tool calls. Without complete request logs, it's nearly impossible to reconstruct "what the agent actually did and why." Compliance frameworks such as SOC 2, ISO 27001, and various industry regulations typically require organizations to demonstrate that system access was appropriately controlled and that critical operations are fully logged and reviewable. For AI-native systems, this means audit logs must capture not just "who called what API and when," but also the context that triggered the call — which agent session it came from, which policy allowed or denied it, and the relevant request payload. Custos builds this layer of logging directly into the gateway, decoupling audit capability from business logic and eliminating reliance on each downstream application to implement its own logging.

Centralized Management That Scales

Custos's governance scope isn't limited to a single API connection. Credential management, organization-level settings, and API keys can all be handled from the same control plane. This means that as the number of tools and AI agents grows, the security model can still be centrally maintained — rather than fragmenting as the scale expands.

Conclusion: From "Do We Trust This?" to "What Is It Allowed to Do?"

The core idea behind Custos is that AI agents can access enterprise tools and APIs — but that access doesn't have to be uncontrolled. By inserting a governance layer in between to enforce policies, control access, and generate auditable records, the question itself is quietly reframed.

Rather than asking "should we trust this AI agent to use enterprise tools?", the better question is — "what is this agent allowed to do?" With Custos, those rules can be centrally defined and enforced. As enterprise AI agents scale to production, governance gateways like this may well become an indispensable part of AI infrastructure.