Choosing Where to Enforce
Vengtoo is the decision engine (the PDP): you send it subject + resource + action, it returns allow or deny. But a decision engine can't enforce anything on its own — something in the call path has to stop and ask it. That something is the enforcement point (the PEP).
For AI agents calling tools, you have three places to put that enforcement point. All three send the same request to the same evaluation endpoint — they differ only in where the check lives and whose code you change.
The three models
| Model | Where the check lives | Whose code changes | Use it when |
|---|---|---|---|
| Gateway | in the middle — a proxy between agent and server | neither — drop-in proxy | you control nothing — off-the-shelf agent talking to a server you don't own |
| Adapter | in the callee — inside the MCP server | the server owner's | you own the server — strongest, cannot be bypassed |
| SDK | in the caller — inside the agent | the agent author's | you own the agent, or you're guarding non-MCP tools |
The adapter is authorization middleware for MCP tools — the exact pattern you use on a microservice endpoint, where the request passes through an authz() middleware before it reaches the handler. Vengtoo ships that same middleware for real HTTP services too (see the framework guides for gin, express, fastapi, …). The MCP adapter just applies it to tool handlers instead of HTTP routes:
microservice: request → [ authz middleware ] → handler
MCP adapter: tool call → [ adapter wrapper ] → tool handler
Deny short-circuits before the handler runs; allow falls through. Tool arguments flow into resource.attributes, so you can write ABAC on them ("allow issue_refund only if amount < 100") — just like middleware inspecting a request body.
How to choose
Ask one question: what do you control?
- Gateway — no code changes anywhere. Point the client at the gateway instead of the server. Best on-ramp; ideal for servers you can't modify.
- Adapter — strongest boundary. The check is inside the resource, so there's no separate channel to route around; the server refuses to act without a decision. Requires you to own the server.
- SDK — the only option when the agent is the only thing you control, and the right tool for non-MCP frameworks (LangChain, custom agents) where there's no MCP server to wrap. Note it's a caller-side self-check: it protects against mistakes and injection, but a rewritten agent could skip it — use the adapter or gateway when you need enforcement the agent can't bypass.
What this means for the MCP Governance console
The console's governance has two layers, and they light up differently per model:
| Console capability | Gateway | Adapter | SDK |
|---|---|---|---|
Policies on mcp_tool + decision log / observability | ✅ | ✅ | ✅ |
| Auto-discovery + approve / block + drift workflow | ✅ | ❌ | ❌ |
The authorization decisions and the audit trail are universal — every model feeds the same evaluation and the same decision log. The discovery / approve / drift workflow is populated by the gateway's tool sync, so it applies to gateway (or another syncing integration) deployments. With the adapter or SDK you write policies against the tool name and get full observability, but tools don't auto-appear in the discovery view.
The one rule
You must put an enforcement point somewhere and point it at Vengtoo. No enforcement point in the path — no gateway, no adapter, no SDK call — means nothing asks Vengtoo, and nothing is governed. That's inherent to authorization, not a limitation: the brain still needs a nerve in the call path. Vengtoo's job is to make that nerve easy to place — as a proxy, as middleware, or as a one-line SDK call.