WardenAuth
AuthorizationAgent SecurityDocsPricingCompareBlogLearn
Sign inStart free

AUTHORIZATION FOR YOUR USERS AND YOUR AI AGENTS

Permissions for your users. Guardrails for your agents.

One permission model for your app and the AI agents that act in it. Try it: pick a role, act as the user, then let their agent try something risky.

Start free Read the docs

SDKs for TypeScript, Go and Python · works with any JWT provider

1 · PICK MARIA'S ROLE
grants tickets:read · tickets:reply · refunds:create (reviewer)
2 · ACT AS THE USER · maria@acme.test
3 · LET HER AGENT TRY · support-bot via MCP

Start with step 2: act as Maria.

AUDIT TRAIL

Nothing yet. Every decision you make in the demo lands here.

Two products. One permission model.

AUTHORIZATION

Stop rebuilding roles and permissions.

  • Deny wins, and every check says why. Matching roles, denying policies and the scope chain on each decision.
  • Multi-tenant by design. Orgs and workspaces as a scope tree with inheritance.
  • The enterprise checklist is done. SSO, SCIM, audit retention, separation of duties.
Explore Authorization →

AGENT SECURITY

Let agents act. Keep the keys.

  • Checks what flows through the tool. Secrets and prompt injection scanned in arguments and results.
  • A person approves the risky calls. Single-use approvals with a written reason.
  • Every decision comes with a receipt. Why it was allowed, signed and verifiable.
Explore Agent Security →

What you don't have to build

The permission work every B2B app ends up doing, already built and tested.

  • Roles and permissions
  • Tenant isolation
  • Org and workspace inheritance
  • An admin screen for your customers
  • SSO and SCIM
  • Audit log with retention
  • Scoped, rotating API keys
  • "Why was this denied?"
const { allowed } = await warden.access.hasAccess({
  subjectId: 'maria@acme.test',
  scopeId:   'eu-support',
  resource:  'tickets',
  action:    'reply',
})

if (!allowed) throw new Forbidden()
{
  "allowed": true,
  "matchedBy": ["role:support"],
  "deniedBy": [],
  "scopeChain": ["acme", "eu-support"]
}

Agent Security, in four steps

From an agent with open access to every tool call checked, approved where needed, and on the record.

  1. 01ConnectPoint your MCP servers at the gateway: GitHub, Linear, Stripe or your own.
  2. 02GrantGive tools to roles. An agent never gets more than the user it acts for.
  3. 03ApproveSensitive tools wait for a reviewer, who writes down why.
  4. 04ProveEvery call leaves a signed receipt and an audit entry.

The same rules for people and agents

Your users

in your app, through your API

Your agents

acting for a user, through MCP

One set of roles and policies

RBAC, attributes and relationships, per tenant. An agent is capped by its user.

DECISION
allowed · reasons
receipt · audit entry

Ready for your enterprise customers

  • SSO · SAML and OIDC
  • SCIM 2.0
  • Immutable audit trail
  • Separation of duties
  • IP allowlists
  • Signed webhooks

Questions

Is WardenAuth a login provider?

No. Your login provider says who someone is; WardenAuth decides what they may do. It works with any JWT provider.

Can I use Authorization without Agent Security?

Yes. Each works alone. Together they share one set of roles, so agents follow the rules your users already have.

How does an agent get its permissions?

Tools are granted to roles, a user consents for their agent, and the agent is capped by that user's own permissions.

Is WardenAuth SOC 2 certified?

Not yet. The controls are in place and certification is in progress.

Which languages are supported?

SDKs for TypeScript, Go and Python, a NestJS module and Express middleware. Everything else talks to the REST API.

Ship permissions this week, not this quarter.

Start freeRead the docs
© 2026 WardenAuth · Built by Ezequiel Carrizo
AuthorizationAgent SecurityPricingUse casesDocsCompareBlogLearnChangelogStatusGlossarySecurityAboutContactTermsPrivacyDPA