TL;DR
- AI-generated code needs an audit trail that is more specific than "the PR passed."
- Open Agent Passport gives agents a stable identity, scoped capabilities, and a revocable authorization surface.
- APort signs policy decisions so GitHub activity can be tied to agent identity, policy, evidence, and outcome.
- The same model works across coding-agent hooks, MCP tools, GitHub Actions, and release workflows.
Audit logs are not enough when agents can act
Enterprise audit systems are good at recording events:
- a workflow ran;
- a user opened a pull request;
- a check passed;
- a package was published;
- a repository setting changed.
AI agents add a new question:
Was the agent authorized to take the action before the system accepted it?
That question needs a decision record, not just an event log.
An event log says what happened. A decision record says what was evaluated, what policy applied, and why the action was allowed or denied.
That is the purpose of Open Agent Passport and APort decisions.
What a passport gives an AI agent
An Open Agent Passport is a structured identity and authorization document for an agent or automation.
It can include:
- agent ID;
- owner ID;
- owner type;
- status;
- assurance level;
- capabilities;
- limits;
- allowed regions;
- contact;
- framework;
- device or runtime metadata;
- issuance and update timestamps;
- signatures and verification material where applicable.
In plain English, it answers:
Who is this agent, who owns it, what can it do, and is it still active?
That is different from an API key. A key authenticates a request. A passport describes the agent and its authorized scope.
What a signed decision adds
A signed decision is the result of a policy verification.
For GitHub and AI coding agent workflows, useful fields include:
| Field | Why it matters |
|---|---|
decision_id
|
Stable reference for audit and incident response |
agent_id or passport_id
|
Connects the action to the agent identity |
policy_id
|
Shows which policy pack was evaluated |
allow
|
Records the authorization outcome |
reasons
|
Explains why the action passed or failed |
assurance_level
|
Captures trust level at decision time |
issued_at and expires_at
|
Makes the decision time-bound |
signature and kid
|
Supports integrity checks |
| GitHub context | Connects decision to repository, workflow, actor, SHA, PR, or push |
| structural findings | Shows protected path changes, workflow risks, and evidence gaps |
This is what makes APort useful for a CISO or platform team. They do not need to ask whether an AI agent "probably" followed instructions. They can inspect the decision.
GitHub context makes the decision operational
For GitHub, the policy engine needs repository evidence.
APort can evaluate context such as:
- repository owner and name;
- event name;
- pull request number;
- base and head refs;
- commit SHAs;
- actor;
- workflow name and run ID;
- changed files;
- commit metadata;
- evidence completeness;
- policy file changes;
- workflow permission changes;
- protected path changes.
This context turns a generic policy into a concrete authorization question:
Can this passport approve or report on this repository action under this evidence?
That is stronger than checking a static allowlist because it includes what actually changed.
Why OAP fits GitHub better than another bespoke audit format
The temptation with AI-agent security is to create a new event schema for every runtime:
- one for Claude Code;
- one for Cursor;
- one for OpenClaw;
- one for GitHub Actions;
- one for MCP tools;
- one for release workflows.
That becomes hard to query, hard to explain, and hard to govern.
OAP gives APort one vocabulary:
- the agent has a passport;
- the requested action maps to a policy pack;
- the policy returns a decision;
- the decision is signed and stored;
- the dashboard displays decisions across agents and owners.
GitHub is then one enforcement point in the same control plane, not a separate product with separate semantics.
Hosted mode and local mode both matter
Most teams should start with hosted mode because it gives:
- centralized decision storage;
- org-level dashboards;
- API-key and passport management;
- suspend and status controls;
- decision search and filtering;
- hosted verification performance.
But local mode matters too.
Some teams need offline enforcement, private environments, or minimal telemetry. A local passport JSON can still define capabilities and limits for guardrail evaluation. That keeps the OAP model usable even when hosted verification is not appropriate.
The important distinction is that hosted mode creates centralized data for governance metrics, while local mode prioritizes offline control.
The CIO and CISO value
For a CIO, the value is deployment without blocking engineering velocity:
- developers can keep using AI coding agents;
- platform teams get a shared control plane;
- report-only rollout reduces friction;
- policy can become stricter over time.
For a CISO, the value is evidence:
- which agents are active;
- what they attempted;
- what was denied;
- where policy is too permissive;
- which repositories have risky changes;
- which workflows changed privileges;
- which actions had incomplete evidence.
For a CTO, the value is operating discipline:
- fewer one-off hooks;
- fewer unmanaged scripts;
- cleaner attribution;
- faster incident response;
- less ambiguity about AI-generated code.
What this looks like in practice
A normal GitHub decision flow can look like this:
- A pull request or push triggers the APort GitHub Action.
- GitHub OIDC proves the workflow identity.
- The Action gathers changed files, commits, workflow evidence, and repository context.
- APort resolves or issues the appropriate hosted passport.
- The Action calls the hosted verifier for a repository policy pack.
- The verifier evaluates passport capabilities, limits, repository evidence, and structural findings.
- A signed decision is returned and stored.
- The workflow either reports the result or enforces it depending on rollout mode.
That flow is intentionally boring. Security infrastructure should be boring. The point is not magic. The point is reliable evidence and predictable enforcement.
What to measure
Once decisions are flowing, the useful metrics are not vanity metrics.
Track:
- number of active passports;
- number of decisions by agent and repository;
- deny rate by policy;
- high-severity structural findings;
- protected path changes;
- workflow permission expansions;
- evidence incomplete events;
- unattributed AI-assisted changes;
- time from deny to remediation.
Those metrics help leadership understand whether AI coding agents are governed or just tolerated.
Bottom line
AI-generated code needs more than source control history. It needs an authorization trail.
Open Agent Passport gives the agent an identity. APort policy verification gives each sensitive action a decision. GitHub integration makes that decision visible where code becomes organizational change.
That is the audit model enterprises need for AI-assisted software delivery.
Frequently Asked Questions
Common questions about this topic.