Skip to main content

What is PolicyArc?

PolicyArc is the authorization layer that sits between your identities and your systems. It applies one policy plane to your applications, identity providers, and AI agents, and it writes its policy decisions to an audit log.

The launch focus for this release is AI agents that call tools over MCP, the Model Context Protocol. The agent access problem explains the problem and what PolicyArc does about it.

PBAC is not limited to agents — it is the same platform that governs employee, partner, and machine-to-machine access. But the launch narrative leads with the agent problem because it is the most urgent gap most organizations have today.

The problems we solve​

  • Agent access is ungoverned. See The agent access problem.
  • Audit gaps. When an auditor asks "who had access to system X on this date," you pull logs from a dozen different applications and hope nothing is missing. PBAC writes the access decisions it makes to one audit log.
  • Integration cost. Every new app, partner, or acquired company is another custom authorization project. PBAC lets you swap bespoke code for policy that any OAuth-speaking app can consume.
  • No single source of truth. Authorization logic is scattered across applications. Your CISO cannot demonstrate compliance posture because there is no one place that governs who can access what.

What you get​

CapabilityWhat it means for you
MCP GatewayA policy check on each tool call an agent makes. See The agent access problem.
Centralized policyRego policies plus policy data in one place. Applies everywhere — applications, resource servers, identity providers. No per-app authorization code.
Every actor, one modelEmployees, contractors, federated partners, M2M services, AI agents — governed by the same policy plane.
Agent identityEach agent is its own client, so policy and the audit log can tell agents apart. See The agent access problem.
Live policy changeA policy change applies to the next checked call. See The agent access problem.
Context-aware decisionsTime, the caller's IP address, MFA status, transaction context. Step-up and obligations at token issuance and at token use.
Standards, not lock-inOAuth 2.0, OIDC, UMA 2.0 resource registration and permission tickets (no requesting party token), OPA Rego. Your clients already speak these protocols. Swap at any time.

Who this is for​

For CISOs and security leaders​

You need to answer three questions before your next board meeting:

  • "Which of our agents can access customer data?"
  • "When did that access happen, and what did they do?"
  • "If we change our policy today, when does it take effect?"

With PBAC, the answers are in the policy data and the audit log — the platform is the answer. Start with The Agent Access Problem.

For solution architects and engineering leads​

You need a control plane that does not require rewriting every integration, that speaks standard OAuth so any MCP client or resource server drops in, and that gives you Rego for the hard policy cases. Start with How it works and First environment.

For the team running agents in production​

You need a fast path to "Claude Code talks to our tools through a gateway that enforces policy." Start with Create your account, the first of the six steps in the First environment track, which ends with a live 403 from Claude Code.

What PBAC protects​

The PBAC Gateway sits in front of each connected upstream API, such as GitHub, GitLab, Google Drive, Jira, and Jenkins. The Connectors section has a page for each documented connector, with the scopes it defines.

PBAC is the same platform underneath for non-MCP authorization too — OAuth 2.0 clients, resource servers, federated identities — but the launch focus is the agent problem. If you have a non-MCP scenario, talk to us.

Next steps​