TL;DR

• Prompt instructions are not authorization.
• Pull request review is necessary, but it is not enough for AI-agent work.
• APort adds signed report-only decisions first, then allows teams to enforce high-confidence rules.
• The most important artifact is not the check mark. It is the decision record behind it.

---

CI tells you whether something passed. It does not always tell you whether it was authorized.

AI-generated pull requests are becoming normal. Developers ask Claude Code, Cursor, OpenClaw, or another agent to implement a feature. The agent edits files, runs tests, creates a branch, and opens a PR.

That workflow can be useful. It can also create a gap:

The repository receives a change, but the organization cannot prove which agent action was authorized under which policy.

Traditional CI is optimized for correctness checks:

• tests pass;
• lint passes;
• build passes;
• dependency scan passes;
• coverage threshold passes.

Those checks are valuable. They are not the same as authorization.

Authorization asks different questions:

• Was this agent allowed to modify this path?
• Was this workflow allowed to publish a release?
• Was this PR allowed to change policy?
• Was this command allowed before it ran?
• Was the evidence complete enough to make a decision?
• Who or what is accountable for the decision?

That is the layer APort focuses on.

Pre-action authorization starts before GitHub

For local coding agents, pre-action authorization runs at the tool-call boundary.

Examples:

• Claude Code PreToolUse hook before Bash, file reads, file writes, web fetches, and MCP tools.
• Cursor guardrail hooks before shell and file operations.
• OpenClaw plugin enforcement before tool execution.

That is the earliest point to stop dangerous actions. If an agent tries to read .env, run a destructive command, or call an unapproved MCP tool, the safest time to deny is before the side effect.

GitHub is the second boundary.

Once the agent's work reaches a pull request or push, APort verifies repository evidence:

• changed files;
• commits;
• protected paths;
• workflow diffs;
• attribution trailers;
• OIDC identity;
• policy version and hash;
• evidence completeness.

The goal is a continuous authorization trail from tool call to repository change.

Why report-only is a serious security mode

Some teams hear "report-only" and assume it is weak. That is not correct.

Report-only is how a security control becomes deployable without causing accidental outages.

In report-only mode, APort can:

• create a signed decision for every evaluated PR or push;
• show which rules would have denied;
• surface protected path changes;
• flag incomplete evidence;
• identify unattributed AI-assisted changes;
• build baseline metrics across teams and repositories.

This gives security teams a map before they enforce.

For AI coding agents, that matters because teams do not yet know every valid workflow. If the first deployment blocks too aggressively, developers will route around it. If the first deployment creates evidence with low friction, the organization learns quickly.

What should move from report-only to blocking

The right first blocking rules are the rules with high signal and low ambiguity.

Rules that often start as warnings:

• package manifest changed;
• lockfile changed;
• protected path touched with valid attribution;
• unpinned GitHub Action introduced;
• large generated diff;
• missing agent trailer on a human-authored PR.

This staged model makes adoption realistic.

Agent attribution matters

AI-generated code should not be anonymous.

That does not mean every commit needs a long footer. It means important repository actions should be linkable to the agent passport and policy decision that authorized them.

Useful attribution includes:

APort-Agent: ap_...
APort-Decision: dec_...
APort-Session: sess_...

When those appear in a commit or PR context, a reviewer can connect the code change to:

• the agent identity;
• the policy pack;
• the allow or deny decision;
• the decision reasons;
• the timestamp;
• the organization or repository context.

That is how an AI-assisted pull request becomes auditable.

The policy should use base-branch trust

One subtle risk is policy self-modification.

If a pull request changes .aport/policy.yaml and the verifier reads policy from the PR head, the PR can weaken the policy that judges the PR.

The safer pattern is:

• use trusted policy from the base branch;
• flag policy changes in the pull request;
• require human review for policy changes;
• only apply new policy after merge.

APort's GitHub structural checks surface this as an explicit finding instead of treating it as a normal file edit.

Public redacted decisions are useful

Not every decision should expose full context publicly. Repository names, paths, reasons, and request context can contain sensitive information.

But teams still need a way to prove that a decision exists and was signed.

The useful split is:

• public redacted decision URL for audit proof and CI output;
• authenticated dashboard for full decision context;
• signed decision payload for integrity;
• policy hash and version for reproducibility.

That gives developers a link they can include in PR checks without leaking internal details.

This is not a replacement for review

APort does not remove human code review. It makes review better.

A reviewer should not have to manually infer whether a workflow change is risky, whether the AI tool touched a protected file, or whether the agent had authority. The review should see those signals already summarized.

The reviewer then decides the human question:

Given the policy decision and evidence, do we want this change?

That is a better use of human attention.

The long-term model: one control plane, many runtimes

An organization may use Claude Code, Cursor, OpenClaw, GitHub Actions, MCP servers, internal agents, and release bots at the same time.

The mistake is to build one-off rules for each runtime with no shared identity or audit model.

APort's model is:

• passport for identity and allowed capabilities;
• policy pack for the action type;
• verifier for deterministic decisions;
• signed record for audit;
• dashboard for governance.

GitHub pull requests are one high-value place to apply that model because they are where agent work becomes organizational change.

Bottom line

AI-generated pull requests need more than a passing CI check.

They need a signed answer to:

Was this action authorized, by which passport, under which policy, using what evidence?

Start report-only. Learn where the risk is. Then block the high-confidence failures.

That is how AI coding agents become usable in serious engineering organizations.

Put this in front of one repository

Start free with report-only evidence for one repository. Upgrade to APort Team
when the repository needs hosted signed decisions, branch protection, and an
organization audit trail that security and engineering can review together.

• Add GitHub Repository Guard
• See APort Team and Enterprise pricing
• Review the Open Agent Passport model