Skip to main content

Vengtoo

Authorization for AI agents, services and users. One policy model, one API, one audit trail. Natively compliant with AuthZEN 1.0.

Vengtoo answers a single question at runtime: can this subject perform this action on this resource? Decisions run in the cloud or on a local agent that sits next to your service, pulls your policy bundle and answers in sub-millisecond time.

When to reach for Vengtoo​

  • You're checking permissions in more than one service and want one source of truth instead of copy-pasted if checks.
  • You need an audit trail of every access decision — who, what, why, and which policy.
  • You're giving AI agents tool access and need to gate what they can actually do.
  • You want to change who-can-do-what without redeploying code.

What Vengtoo does​

  • POST /access/v1/evaluation — the only endpoint your application has to call. Returns decision plus a context object with reason, access_path and policy_id.
  • Authorization, not authentication. Bring your own identity provider — Auth0, Clerk, Cognito, Okta, or your own login. You authenticate users; Vengtoo decides what they can do. You never send us your users' identity tokens — each check carries only an opaque subject ID.
  • Author policies from the dashboard or as code with the Terraform provider — or send them over the REST API.
  • RBAC + ABAC + direct grants. All three access paths evaluated in one request.
  • Local agent option. Same API, sub-millisecond decisions, decisions stay on your network.
  • Dogfooded. The Vengtoo admin dashboard gates its own features through a local Vengtoo agent.

Get started​

New to Vengtoo? Quick Start takes you from zero to a working access check in about 10 minutes.

From there, pick the path that matches what you're protecting:

Authorizing users, services and devices​

Classic backend authorization — before letting a request through, your code asks Vengtoo whether the subject is allowed. It's a single API/SDK call, so the check can live anywhere your code runs: a microservice, a serverless function, even a script on a Raspberry Pi at the edge. The subject can be any principal — a user, a service, an IoT device, a robot. Create a resource and a policy, assign your subject, then call /access/v1/evaluation from an SDK or directly.

Authorizing AI agents​

You're giving an AI agent tool access and want to gate which tools it can call — especially destructive ones. How you integrate depends on how those tools are exposed:

  • MCP Gateway — a drop-in proxy between your MCP client (Claude Code, Cursor, Copilot) and any MCP server. No code changes to the server; every tool call is authorized before it's forwarded. Best when you're connecting to servers you don't control.
  • MCP Adapter — a library you embed in your own MCP server. One line (wrapAllTools(server)) routes each tool call through Vengtoo. Best when you author the server.
  • Not using MCP? For a LangChain tool set or a custom agent, call the SDK inside your tool — the same check as any backend authorization, just at the tool boundary.

Either way, tool arguments land in resource.properties, so you can write ABAC rules like "support_rep can invoke issue_refund only if amount < 100".

Want decisions on your own infrastructure?

Run decisions locally with the Vengtoo Agent. Deploy the Vengtoo Agent alongside your application for sub-millisecond authorization decisions whose inputs never leave your infrastructure. The agent syncs policies from Vengtoo Cloud and evaluates them locally — so if the cloud is unreachable, it keeps serving from a cached bundle without interruption. Same API, zero code changes.

Under the hood​

Your app  ─────►  /access/v1/evaluation  ─────►  { decision, context: { reason, policy_id, access_path } }
                       │
                       └── cloud (api.vengtoo.com) or local agent (localhost:8181)

Same endpoint shape, same response, whichever you point at.

Next steps​

  • Quick Start — Authorization model in 10 minutes.
  • MCP Adapter — Gate an MCP server's tool calls.
  • Vengtoo Agent — Run the agent locally. Metrics, decision logs, warm cache.
  • Concepts — Authorization model, access paths, policies.
  • API Reference — Full request/response for /access/v1/evaluation.