oakGuard

Preview

oakGuard governs the agent you already have. If you run a Copilot Studio, Claude, or ChatGPT agent that can add a remote MCP server over OAuth, add oakallow and connect your own MCP server. From then on every call your agent makes to that server is permission-checked, gated behind human approval when it is risky, recorded with a signed receipt, and impossible to route around.

The short version

You do not adopt a new agent. You add one connection to the agent you have, register your MCP server in oakallow, and every tool call travels through the governance layer because that is the only route to your server. Remove the connection and the agent has no tools, not ungoverned ones. That is what makes the authority unremovable.

Two ways to connect, one of them unbypassable

An agent can reach oakallow in two shapes. In advisory mode the agent holds a connection to your server directly and a separate connection to oakallow, and an instruction tells it to check first. That is real governance, but a misbehaving agent or a determined maker can step around it. oakGuard is the other shape: the agent holds only the oakallow connection, and your server is reached through it. There is no direct path to bypass.

Two connection models. In advisory mode the agent connects to both oakallow and your MCP server directly and is told by instruction to check permission first; the agent can skip the step or a maker can remove the guard, and oakallow never touches the call. In oakGuard gateway mode the agent holds only one connection, to oakGuard, which checks, approves, forwards, and audits before reaching your MCP server; there is no path to your server except through oakGuard.
One connection, not two

The agent adds a single MCP connection, to oakallow. Your servers are registered in oakallow, not wired into the agent, so there is nothing to remove and no second endpoint to call directly.

Unbypassable by construction

Governance is the transport, not a rule the agent is asked to follow. The only route to your server runs through the permission cascade, so a skipped instruction or a stripped connector cannot get around it.

Your servers, your labels

Connect any OAuth 2.1 MCP server. Rename it, give it an icon, pause or disconnect it, all without touching the oakallow connection your agent depends on.

How a governed call runs

Every call takes the same path. oakallow decides, then forwards. It does not implement your tool; your server executes it against its own data. A safe call clears immediately and returns with a signed receipt. A risky one is held with a reference number until a named human approves it on a separate, MFA-bound surface, and only then does the retry forward.

How a governed call runs. The agent calls a tool; oakGuard runs the permission cascade, requires human approval when the action is risky, and issues a signed receipt. When allowed, oakGuard forwards the call to your MCP server, which executes it; the result returns to the agent with the signed receipt. When approval is required, the call is held with a REF until a human approves on a separate device, and once approved the retry forwards.
Decide, then forward

oakallow is the transport, not the executor. It runs the cascade and, if cleared, forwards the call. Your server holds the business logic and touches its own data; oakallow runs none of it.

Human in the loop, by reference

A risky call returns a REF instead of running. The approver decides in the oakallow app under enforced multi-factor auth; the agent polls the REF and the retry executes exactly once, never twice.

Signed and auditable

Every governed call carries a signed decision receipt and lands in an immutable audit log, so what ran, who approved it, and when are all provable after the fact.

What oakGuard does with your data

Being unbypassable means being in the request path, the same trust posture as any API gateway, WAF, or reverse proxy you already run. oakallow transits governed calls over TLS on both legs and does not retain the payloads. It is candid about this rather than claiming it never sees your traffic, because in gateway mode it does, in flight, and then forwards it.

What oakGuard does with your data. oakGuard transits governed calls over TLS: it decrypts the downstream token in memory, runs the cascade, forwards the call, and passes the response straight back, with nothing cached. It retains governance data only: the verdict, the REF, the signed receipt, who acted, which server, and when. It does not retain tool arguments or response bodies or your customers' data.
Encrypted in, encrypted out

Both legs are TLS. oakallow refuses to connect a server that does not meet OAuth 2.1, and the downstream token is decrypted only in memory for the life of the request.

Payloads are not retained

oakallow records the decision, the reference, and the receipt, never the tool arguments or the response bodies. Governance data is kept; your customers' data is not.

Exposure goes down, not up

Your server was already reachable at its URL. oakGuard adds a consented, revocable checkpoint in front of it. Revoke it and oakallow loses access instantly.

Add it to the agent you already have

1

Connect your MCP server in oakallow

Open the oakGuard tab in your oakallow dashboard, add your server's URL, and authorize access once. Its tools are registered as drafts for you to review and set a policy on.
2

Add the oakallow MCP to your agent

In Copilot Studio: add a Model Context Protocol tool with OAuth 2.0 dynamic discovery. In Claude or ChatGPT: add a custom connector. Point it at https://api.oakallow.io/mcp and sign in.
3

Run governed work

Your agent now reaches your server through oakallow. Safe calls pass with a receipt; risky ones wait for a human. You can rename, pause, or disconnect any server without ever touching the agent.

An oakallow account is required for the connection to work. oakGuard is in preview; the connect-and-authorize step and the reconnect behavior for newly added tools are still being smoothed.

Get started free Read the MCP docs