OAGOpen Agent Governance
Implementation packs
Deployment-first · Standards-aligned · Vendor-neutral

Open Agent Governance
for the agentic internet.

AI agents are already connecting to GitHub, Slack, Salesforce, ServiceNow, cloud APIs, payment wallets and internal tools. Open Agent Governance gives enterprises a practical control layer for what agents are allowed to do — before actions execute.

  • Refuse insufficient proof
  • Verify bounded authority
  • Bring humans back when risk rises
  • Execute through doorkeepers, not standing credentials
  • Emit receipts for every consequential action
Explore the GitHub pilot View implementation packs
Action flowverified · bounded · auditable
Agent request
↓
Doorkeeper
↓
Policy decision
↓
HAPP approval (if required)
↓
WAUTH capability
↓
Tool / API execution
↓
Receipt

The agent may request. The doorkeeper decides. The lock verifies. The receipt proves.

01 / Why this matters now

The standards will matter.
But the risk is already here.

Enterprises are wiring agents into real systems before the identity and authorisation landscape has converged. MCP servers, OAuth tokens, SaaS connectors, browser agents, coding agents and payment wallets are already creating a new control surface. Waiting for a perfect universal agent identity standard is not an option.

01

Agents are getting access

Agents are being connected to SaaS systems, code repositories, ticketing tools, collaboration platforms and internal APIs.
02

Identity is not enough

Knowing which agent is acting does not prove what it is authorised to do.
03

Controls must sit outside the model

Prompt instructions are not enforcement. The lock must live at the tool, API, gateway or relying-party boundary.
“Policy inside the prompt is guidance. Policy at the doorkeeper is enforcement.”

02 / The problem

Today’s systems confuse access with authority.

AI agents often operate through standing OAuth tokens, user sessions, service accounts or broad SaaS permissions.

From the target system’s perspective, an agent action can look identical to a human action.

Existing PAM and JIT access tools were built for humans at keyboards, not autonomous agents.

If an agent has the credential, the model can attempt the action.

In an incident, enterprises need to know whether a human consciously approved the action — or whether the agent acted autonomously.

Old model
Agentic problem
Human requests access
Agent can request access
Manager approves
Agent may manipulate or trigger approval paths
User checks out credential
Agent may act with standing access
Logs show user action
Logs may not distinguish human vs agent
MFA at login
Does not prove approval of a specific action

03 / The solution

Verified authority, not just verified identity.

Identity proves who or what is involved. Authority proves what may happen. Open Agent Governance turns agent actions into bounded, verifiable, auditable events.

Layered stack
Identity evidence
→
Delegation
→
Policy
→
Human return-point
→
Capability
→
Execution
→
Receipt
WAUTH

The lock

A relying party, MCP gateway or SaaS doorkeeper refuses insufficient proof, verifies a bounded capability and emits a receipt.
HAPP

The human return-point

When risk rises, the human returns through passkey, liveness, wallet, enterprise step-up or another approval method.
OAG

The runtime layer

Policies, doorkeepers, profile adapters, skills, implementation packs, tool-trust boundaries and receipt infrastructure.
“OAuth can get the agent to the tool. WAUTH decides whether the agent may use the tool for this action. HAPP proves human approval when required.”

04 / Minimum viable lock

The minimum is deliberately small.

At minimum, a relying party only needs a small lock: refuse insufficient proof, verify bounded authority, and emit a receipt. Everything else is a profile.

01

Refuse insufficient proof

Return a structured challenge when the agent lacks authority.

02

Verify bounded authority

Check audience, expiry, action scope, proof binding, approval references and replay.

03

Emit a receipt

Record what was requested, verified, approved, executed, refused or revoked.

This is how a single API, merchant, SaaS connector or MCP server can adopt first — without waiting for the entire ecosystem to agree.

05 / How it works

One small flow.
Four risk tiers.

AI Agent
↓
MCP Doorkeeper
→
Policy decision
Allow T0
wauth_required
Deny
→
HAPP approval
↓
WAUTH capability
↓
Tool / SaaS / API
↓
Receipt
T0 · Observation
See, not act. Mediated and logged.
T1 · Low-risk action
Acknowledgement.
T2 · High-risk action
Passkey / strong approval.
T3 · Exceptional action
Liveness / biometric approval.
“T0 gives the agent eyes, not hands. Higher tiers unlock action only with proportionate proof.”

06 / First pilots

Start where the risk is concrete.

Pilot 01● live brief

GitHub Coding Agent Authorisation

Coding agents have a high blast radius. A compromised or misbehaving agent can merge code, alter infrastructure-as-code, introduce vulnerabilities or access CI/CD secrets. The GitHub pilot routes the agent through an MCP doorkeeper instead of giving it standing credentials.

Flow
Codex / coding agent→MCP GitHub Doorkeeper→T0/T1/T2/T3 policy→HAPP approval→WAUTH capability→GitHub App execution→Receipt
  • T0read PR metadata / CI status
  • T1create branch / comment / low-risk change
  • T2merge to main with passkey approval
  • T3force push / CI bypass / branch protection change with liveness approval
View GitHub pilot
Pilot 02● live brief

Agentic SaaS JIT Access

Existing PAM tools were built for humans and infrastructure credentials. Agentic SaaS JIT access controls what an agent may do in Slack, GitHub, Salesforce, ServiceNow, Okta, Box and similar tools.

Flow
Agent request→Policy→HAPP / liveness if required→SCIM/OIDC/PAM bridge→Time-limited grant→SaaS action→Revocation→Reconciliation receipt
  • Slackpost to channel · DM external · file export
  • Salesforcedata export · mass update · admin change
  • ServiceNowticket approval · workflow change
  • Oktauser provisioning · role assignment
View SaaS JIT pilot

07 / Components

A deployable governance stack.

01

MCP Doorkeeper

Sits in front of tools and APIs. Classifies requests. Refuses insufficient proof.
02

Policy Engine

Evaluates action, context, principal, agent, repository, data sensitivity, risk tier and tool trust boundary.
03

HAPP Connector

Integrates passkeys, liveness, digital credentials, enterprise step-up, wallets or approval workflows.
04

WAUTH Capability Issuer

Mints short-lived, scoped, action-bound authority tokens.
05

Receipt Store

Records requests, decisions, approvals, capabilities, executions, revocations and reconciliation.
06

Implementation Packs

Codex/Claude-ready build packs with architecture, code tasks, smoke tests, done criteria and rollback notes.
07

Profile Registry

A marketplace-like catalogue of trusted profiles, doorkeepers, skills and integrations.

08 / Ecosystem

A marketplace of trusted profiles —
not a monolithic standard.

Open Agent Governance should not become one giant protocol. The core stays small. The ecosystem grows through profiles, adapters, skills, doorkeepers and implementation packs.

Categories
Core locksHuman return profilesSaaS connectorsCommerce profilesIdentity evidence profilesPolicy adaptersReceipt infrastructureAgent SkillsImplementation packs
Profile examples
  • GitHub coding agent profile
  • SaaS JIT access profile
  • Entra claims challenge profile
  • iProov / HAPP liveness profile
  • Digital Credentials / Apple / EUDI profile
  • Link agent wallet profile
  • Solid Pod access bridge
  • DNSid ownership anchor
  • Microsoft AGT adapter
  • Verifiable Intent bridge
“A skill can teach an agent how to obtain proof. It must never itself grant authority.”

09 / Why this is different

Not another identity provider.
Not another AI guardrail.

Category
What it does
What is missing
Agent identity
Names the agent
Does not prove authority
OAuth scopes
Grants access to services
Often too broad for action-level control
Prompt guardrails
Guide model behaviour
Not reliable enforcement
PAM / JIT
Controls human privileged access
Not designed for autonomous agents
MCP
Connects agents to tools
Needs governance at the action boundary
Open Agent Governance
Verifies bounded authority before execution
Designed to compose with the rest
“MCP is the pipe. WAUTH is the lock. HAPP is the human return-point.”

10 / Use cases

Where verified authority matters.

Coding agents merging code

A merge is a deployable state change — it deserves explicit human approval.

Slack actions and workspace posting

Outbound messages to external parties can move markets and reputation.

Salesforce data changes and exports

Customer data export is a regulated event, not a query.

ServiceNow approvals

An approval is a binding decision; the approver must be human-bound.

Okta provisioning

Granting access grants future authority; treat as high-tier.

Account recovery

Recovery flows are favourite targets — bind to liveness.

Data export

Exfiltration shaped as productivity needs proportionate proof.

Deployment approvals

Production cutovers must distinguish agent from human consent.

Agentic payments

Money movement is irreversible — capability tokens scope amount, payee and time.

Government forms and submissions

Submission equals legal assertion — receipts become evidence.

Regulated enterprise workflows

Audit needs the chain, not just the outcome.

11 / Trust & audit

Receipts turn agent actions into evidence.

In agentic systems, “the agent said it did X” is not enough. A receipt proves what was requested, approved, authorised, executed, refused, revoked or reconciled.

Sample receipt chain
  1. 01Agent request receipt
  2. 02Policy decision receipt
  3. 03HAPP approval receipt
  4. 04Capability issuance receipt
  5. 05Tool execution receipt
  6. 06Revocation receipt
  7. 07Reconciliation receiptverified chain

Audit-grade deployments should be able to reconstruct protected actions after the fact: agent, principal, policy, approval, capability, tool call, outcome and receipt.

12 / Deployment options

Deploy where the risk lives.

01

Managed

For pilots, startups, smaller teams, fast deployment.
02

Self-hosted

For banks, governments, defence, healthcare, critical infrastructure, source-code security.
03

Hybrid

Common enterprise pattern: self-hosted doorkeeper and receipt store, managed liveness/approval provider, external profile registry.
“The lock can be local. The evidence can be portable. The profiles can be shared.”

13 / Get started

Start with one agent, one tool,
one lock.

You do not need to wait for the whole agentic ecosystem to standardise. Start with one high-risk workflow, put a doorkeeper in front of it, require bounded authority, and record receipts.

Explore implementation packs Read the WAUTH modelRun the GitHub pilot

Stop waiting for standards to finish. Deploy bounded, auditable agent authority now.