Delegated authority
that provably attenuates.
When the actor isn’t the principal — background jobs, service chains, support impersonation, AI agents — the borrowed authority never exceeds its source.
No new policy language to learn, works with
Delegated authority
The actor is not the principal
Whoever makes the call and whoever the call is for are two different identities. Most systems record one and enforce the other. Vengtoo keeps them apart on purpose.
The narrowest link caps the whole chain
Person → orchestrator → tool-runner. Authority originates at the person and is narrowed by every scope along the way. The tightest hop wins, not the most recent one.
A delegated caller still hits the gate
Mark an action as requiring approval and it holds even for a delegated request. Acting on someone’s behalf is not a way around the control.
Every decision names the chain that authorized it
Allow or deny, the reason code, and the ordered delegations behind it — recorded per decision, queryable, and exportable to your SIEM.
The same thing, run against production
POST /access/v1/evaluation
| alice reads — she holds the policy herself | ALLOW | |
| agent reads — before any delegation exists | DENY | NO_POLICY_MATCH |
| agent reads — delegated by alice, scope [read] | ALLOW | |
| agent writes — outside the delegated scope | DENY | delegation_scope_denied |
| agent reads — after the delegation is revoked | DENY | NO_POLICY_MATCH |
Lines two and three are the whole argument. The agent holds no policy of its own, so the ALLOW is alice’s access, borrowed and line five shows revoking takes it back rather than leaving standing access behind. How it is enforced
Every caller. One engine.
AI agents now make more decisions than your users do.
For users, services, devices, and AI agents, every decision is centrally enforced, audited, and explainable.
Agent tool gating
Every tool call is evaluated against policy before execution. Grant only the permissions an agent needs, only for as long as it needs them.
Scoped delegation
Delegated access is scoped, time-limited, and never exceeds the delegator's own permissions. Revoke the human and the agent loses access on its next call. Gate the actions you choose behind human approval.
User & workspace authorization
RBAC, ABAC, and group-based access. Model teams, workspaces, or tenants with the same primitives. Stop scattering if (user.role === "admin") across every controller.
Machine-to-machine authorization
Replace scattered, hardcoded authorization checks with one policy engine. Every API call, CI/CD pipeline, and device gated the same way.
Decision log
Explain every authorization decision.
Every authorization decision includes who requested access, what was evaluated, which policy matched and why it was allowed or denied.
Environment
Vengtoo
john@vengtoo.com
Decision ID
a1b2c3d4-e5f6-7890-abcd-ef1234567890
Timestamp
1s ago
Access Path
DIRECT
Agent
prod-agent-us-east
Called by
oauth · svc-checkout
subject=svc_checkout_8a3f · resource=res_orders_api_4b2c · policy=pol_orders_read_7d1e
AI Explanation
checkout-service is granted read access to orders-api because it is directly assigned to the policy orders-read-access, which permits this action. The access path is direct, meaning no role or group membership was needed to resolve this permission.
Decision ID
3f2a0d64-8091-4bd7-8772-fe959849d1b3
Timestamp
3s ago
Access Path
DELEGATION
Agent
prod-agent-us-east
Called by
oauth · svc-support-desk
On behalf of
usr_dana_9f2e
Delegation chain
fe05b9f7-8091-4bd7-8772-fe959849d1b3
subject=agt_refunds_5c1a · resource=res_refund_8812 · policy=pol_refund_issue_2f9b
How it works
Your code knows its shape. It can't know who's allowed.
Vengtoo scaffolds the structure it can read out of your codebase, gives you one place to decide the part it can't, and explains every decision that follows.
Integrations
Plug in wherever you already enforce.
Vengtoo doesn't ask you to replace your infrastructure. Authorize at the API gateway, the agent framework, or the MCP layer, wherever your requests already flow through.
API gateways
Native ext_authz support, point your existing gateway at Vengtoo, no plugin required.
Kong
Envoy
AWS API GatewayAgent infrastructure
Tool-call authorization for the frameworks routing your AI agents.
IBM ContextForgeMCP
Expose your MCP server to Claude or ChatGPT through a tunnel, with every tool call authorized before it runs.
Claude
OpenAI
Cloudflare tunnelsSIEM & SCIM
SoonStream decisions to your SIEM, and keep subjects and roles in sync as people join, leave, or change teams.
MCP Governance
Every MCP tool your agents can call, discovered, reviewed, and approved.
Run the Vengtoo MCP Gateway in front of your MCP servers and it automatically discovers every tool they expose. New or changed tools sit in Pending until a human approves them.
Environment
Vengtoo
john@vengtoo.com
Govern and secure your MCP ecosystem
Tools Overview
All tools discovered across your MCP servers
| Tool name | Server | Status | Last seen | Change |
|---|---|---|---|---|
list_tables List all tables in the database | database | Approved | 3d ago | — |
query Execute a read-only SQL query against the database | database | Approved | 3d ago | — |
execute Execute a write SQL statement (INSERT, UPDATE, DELETE…) | database | Blocked | 3d ago | — |
send_email Send an email via the notifications service | notifications | Pending | 2m ago | NEW |
Showing 4 of 4 tools
Pending Approvals
2Recent Activity
| Time | Event | Details | Actor |
|---|---|---|---|
| 2m ago | approve | approve: send_email (notifications) | alice@acme.com |
| 1h ago | discover | discovered 3 new tools on gw_staging | system |
Gateway & server visibility
Every Vengtoo MCP Gateway you run, the servers behind it, and every tool they expose, with live online/offline status.
Pending approvals
New tools, and tools whose schema changed, sit in Pending until a human approves or blocks them. Nothing executes silently.
Schema drift detection
If a tool's inputs or behavior change after approval, Vengtoo flags it for re-review instead of trusting the original grant forever.
Full audit trail
Every discovery, approval, and block is logged: what changed, when, and who acted on it.
Migration
Already running Cedar, OPA, Casbin, or something homegrown? Move to Vengtoo without a big-bang cutover.
Run /vengtoo-migrate in your coding agent, and it translates what maps cleanly, flags what doesn't, and runs in shadow mode next to what you have today, so you can verify it matches before anything depends on it.
Discover
Point it at your existing Cedar, OPA/Rego, Casbin, or homegrown RBAC code and inventory what's actually in use.
Translate
Convert discovered policies into Vengtoo's model: RBAC, ABAC, and direct grants, mapped one to one where possible.
Shadow
Run Vengtoo alongside your current system in shadow mode. Every decision is compared, nothing is enforced yet.
Cutover
Once shadow results match, flip enforcement to Vengtoo. Roll back at any time, nothing is deleted from the old system.
Environments
Build and test in staging. Promote to production when you're confident.
Every environment keeps its own isolated policy set. Preview exactly what a promotion will change, promote only what you choose, and roll back instantly if something's wrong.
Environment
From
To
Why Vengtoo
Add authorization without touching how you authenticate.
Vengtoo sits downstream of authentication. It never sees credentials, whether that's a third-party IdP or something you built yourself.
No identity tokens, ever
Your identity provider verifies who someone is. Vengtoo only ever sees an opaque subject ID, never a password, session token, or OAuth credential. There's nothing to steal, because we never hold it.
Never locked into an identity provider
Mix identity and authorization in one platform, and switching your IdP means rewriting how you check access everywhere. Vengtoo only ever sees an opaque subject ID, so swapping Okta for Auth0, or migrating off either, leaves your policies unchanged.
Agents only ever get narrower access
An orchestrator can pass a scoped, time-limited slice of a person's access to a sub-agent for one task. Every hop can narrow it; none can widen it, and revoking any link removes it everywhere below. Same policy engine, same decision log, whether the caller is a person, a service, or an agent.
AI explains every decision, and how to fix it
Every allow or deny comes with a plain-language explanation and a suggested next step, generated from the actual policy that matched. Compliance and debugging without parsing raw decision codes.
Dogfooded
Vengtoo secures Vengtoo. Every authorization decision in Vengtoo is evaluated by the same Vengtoo Agent and authorization engine we ship to customers.
Questions
Before you ask.
No. Vengtoo is authorization only, it decides what an already-authenticated user, service, or agent is allowed to do. Pair it with any IdP: Okta, Auth0, Keycloak, or your own.
The Vengtoo Agent evaluates policy locally, in-memory, with no round-trip to the cloud on the hot path, and syncs from the cloud in the background. If the cloud is unreachable, the agent keeps enforcing the last policy it synced: no open-fail, no outage-shaped security hole.
Agents authorize the same way users and services do, same policy engine, same decision log, with support for scoped, time-limited delegation, so an orchestrator can hand a sub-agent exactly the permissions it needs for one task, never more.
A standard request/response shape for authorization decisions, so you're not locked into a proprietary API. If you outgrow us or want to run a second PDP, AuthZEN-conformant tooling on both ends speaks the same language.
You model it as policy: RBAC, ABAC, or direct grants, in YAML, JSON, Terraform, or the dashboard. Most teams replace scattered if-checks incrementally, endpoint by endpoint, not in one migration.
Yes, start free, no credit card required, and make your first authorized call right away.
Stop writing authorization code.
Build your product.
Make your first authorized call — for a user, a service, or an agent — and see every decision logged and explained. Free to start.