TL;DR

• AI coding agents now touch repositories, workflows, secrets, pull requests, and releases. That requires authorization, not just prompts.
• APort uses GitHub OIDC to identify the workflow, then evaluates repository activity with an Open Agent Passport (OAP).
• Every verification returns a signed decision record: allow or deny, policy ID, reasons, evidence context, and provenance.
• The GitHub path starts report-only by default so teams can see risk before blocking merges.

---

GitHub is becoming the control surface for AI coding agents

Most AI coding agent risk does not start with a chat response. It starts when the agent tries to act:

• open a pull request;
• edit a GitHub Actions workflow;
• touch a deployment script;
• add a package or lockfile change;
• push directly to a protected branch;
• publish a release;
• modify the policy that is supposed to govern it.

Those actions already pass through GitHub. That makes GitHub the right place to begin enforcing an agent security control plane.

The question is simple:

What proves this AI-assisted change was authorized before it reached production?

For human developers, GitHub gives us identity, branch protection, review rules, audit logs, and workflow permissions. AI agents need the same kind of control, but with one extra property: each agent action needs a policy decision that can be reviewed later.

That is what APort adds.

The architecture: GitHub OIDC plus Open Agent Passport

APort's GitHub control-plane work is built around three pieces:

The important design choice is that OIDC authenticates the workflow, but the passport authorizes what it can do.

OIDC answers:

Is this really the GitHub workflow it claims to be?

OAP answers:

What is this workflow or agent allowed to do?

The decision record answers:

What happened, what policy applied, and why was it allowed or denied?

Why not just use a GitHub secret?

Secrets are easy to start with and hard to govern at scale.

If a workflow stores a long-lived API key, the blast radius is tied to the key. If that key leaks, gets copied to another workflow, or is reused across repositories, the authorization boundary becomes blurry.

GitHub OIDC is better for this use case because the workflow can exchange a short-lived identity assertion for authorization. APort can bind the issued or reused passport to GitHub context:

• repository owner and name;
• workflow file and run ID;
• ref and commit SHA;
• actor and event name;
• organization or installation context where available.

That gives security teams a concrete evidence chain without asking developers to manage another static credential.

What the GitHub policy verifies

The first GitHub policy target is repository change control. In APort policy terms, that maps to policy packs like:

code.repository.merge.v1
code.release.publish.v1

The GitHub Action gathers evidence before calling the hosted verifier:

• changed files;
• changed commits;
• pull request metadata;
• push compare ranges;
• workflow file patches;
• commit authors and trailers;
• structural findings such as protected path changes or unsafe workflow edits.

APort then evaluates the request using the same verification service used by Claude Code, Cursor, OpenClaw, and other agent guardrails:

POST /api/verify/policy/{pack_id}

The result is a signed decision. For report-only mode, the workflow can continue while still producing an audit record. For enforcement mode, a deny decision can fail the check.

Why push events matter

Many security systems start with pull requests only. That misses a real class of incidents.

A compromised token, poisoned automation, or overly privileged workflow may push directly to a branch. It may also update generated files, deployment configuration, or GitHub Actions workflows outside the normal pull request path.

That is why APort's GitHub evidence collection handles both:

• pull request files and commits;
• push compare evidence between the before and after SHAs.

If GitHub cannot provide complete evidence, APort treats the repository analysis as incomplete. That is not a low-severity logging detail. Incomplete evidence can hide exactly the files security teams care about.

For example, if the verifier cannot see whether .github/workflows/deploy.yml changed, the safe answer is not "looks fine." The safe answer is "evidence incomplete."

What gets protected first

Every team will tune policy differently, but the default protected paths are intentionally conservative:

The goal is not to block all changes to those files. The goal is to make changes visible, attributable, and governed by policy.

The decision shape security teams need

APort decisions are designed to be useful after the moment of enforcement.

A decision can include:

• decision_id;
• passport or agent ID;
• policy ID;
• allow or deny result;
• reason codes and messages;
• assurance level;
• issue and expiry timestamps;
• signature and key ID;
• GitHub repository context;
• structural findings;
• evidence completeness indicators.

That gives the CISO, CTO, platform team, or auditor a record that is more specific than "CI passed."

It answers:

• Which agent or workflow made the request?
• Which repository and ref were involved?
• What changed?
• Which policy was evaluated?
• Was the decision signed?
• Were there protected path changes?
• Was evidence complete?
• Did the request get allowed, denied, or logged report-only?

Report-only is not weak

Report-only is often the right first deployment mode.

Security teams do not need to guess which rules will cause noise. They can turn on APort, gather signed decisions, inspect findings, then decide which policies should become blocking.

That path is especially important for AI coding agents because teams are still discovering their real workflows. A hard block on day one can create friction. Silent audit creates visibility. The right default is visibility first, enforcement when the signal is understood.

How this fits with Claude Code, Cursor, OpenClaw, and other agents

GitHub is one layer. Runtime guardrails are another.

APort can run at the coding-agent tool boundary, such as a Claude Code PreToolUse hook, and it can run again in GitHub as repository evidence moves toward merge.

Those controls complement each other:

That is the control-plane model: one passport identity, multiple enforcement points, signed decisions across the workflow.

Bottom line

AI coding agents are becoming part of the software supply chain. GitHub is where their work becomes code, release artifacts, and production change.

APort's GitHub control plane gives that work a passport, a policy decision, and an audit trail.

That is the difference between trusting an agent because it sounded confident and trusting a workflow because every sensitive action has a signed authorization record.