TL;DR

• AI coding agents can change the files that control CI, releases, dependencies, and policy.
• GitHub security for agents should focus on protected paths, workflow changes, push evidence, and attribution.
• APort turns those signals into signed policy decisions instead of only another CI log.
• The safest rollout is report-only first, then blocking enforcement on high-confidence findings.

---

The dangerous files are not always application code

When people think about AI coding agent risk, they usually imagine a bad code diff. That is real, but it is not the whole risk.

The more interesting attack is changing the files that control the repository:

• .github/workflows/deploy.yml;
• a local GitHub Action under .github/actions/;
• package.json;
• package-lock.json, pnpm-lock.yaml, or yarn.lock;
• next.config.js;
• a policy file;
• a release script;
• an IaC or deployment path.

Those files decide how code gets built, tested, released, and deployed. If an agent or poisoned dependency changes them, the impact can be larger than a normal application bug.

This is why APort's GitHub policy work starts with protected paths.

What a protected path policy does

A protected path policy does not mean "never change this file."

It means:

If this file changes, create stronger evidence before the change is trusted.

That evidence can include:

• who authored the commit;
• whether the commit has an agent attribution trailer;
• whether a signed APort decision exists;
• whether GitHub evidence was complete;
• whether a workflow diff was available;
• whether the policy itself changed in the pull request;
• whether the change expanded permissions or introduced risky triggers.

This gives teams a practical security model. Developers can still change important files, but those changes are visible and governed.

Why GitHub Actions need special handling

GitHub Actions workflows are powerful. They can receive tokens, run shell commands, publish packages, deploy infrastructure, and call external services.

That makes workflow changes high value for attackers and high risk for AI-assisted automation.

APort's GitHub Action looks for structural findings such as:

This is not generic static analysis. It is policy evidence for the authorization decision.

Pull requests: useful, but not enough

Pull request evidence is straightforward:

• list changed files;
• list commits;
• inspect workflow patches;
• inspect commit trailers;
• build context for policy verification.

For AI coding agents, attribution matters. APort can look for trailers such as:

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

Those trailers let a GitHub change link back to the agent passport and decision history.

But pull requests are not the only event that matters.

Push events need first-class evidence

Direct pushes and automation pushes can be high risk. They may be normal for a release bot, a dependency bot, or an internal automation workflow. They may also be the path an attacker uses to bypass review.

APort's GitHub control-plane implementation handles push events by using the GitHub compare API for the pushed range:

before SHA ... after SHA

That produces changed files and commits for the push, not just a raw event payload.

If the range cannot be fetched, or if GitHub cannot provide complete file or commit evidence, the Action marks evidence incomplete. That should not be hidden. Incomplete evidence is a security signal.

The practical rule is:

If the system cannot see enough to evaluate the repository change, it should not silently claim the change is safe.

The backslash path bug that matters more than it looks

GitHub repositories can contain filenames with literal backslashes on Linux runners. That is unusual, but security logic must handle unusual paths correctly.

The wrong approach is to normalize every changed repository path by converting backslashes to forward slashes.

That can make this root-level filename:

src\payload.js

look like this nested path:

src/payload.js

If policy says src/, the normalized version can match even though the repository path is a different literal filename.

APort now treats policy patterns and repository paths differently:

• policy patterns can normalize backslashes to forward slashes because policy authors often type Windows-style separators;
• repository paths preserve literal backslashes because they are evidence, not user-friendly input.

This is a small implementation detail with a large security lesson: do not rewrite evidence until it changes meaning.

How to configure a GitHub workflow

The hosted GitHub path should use OIDC, not a long-lived API key.

A minimal workflow shape looks like this:

permissions:
  contents: read
  pull-requests: read
  id-token: write

jobs:
  aport-policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Verify repository policy
        uses: aporthq/policy-verify-action@v1
        with:
          mode: auto

The exact Action distribution may differ by repository, but the security posture should not:

• id-token: write is required for GitHub OIDC;
• contents: read lets the Action inspect repository files;
• pull-requests: read lets it inspect PR metadata where applicable;
• mode: auto is the safe default for rollout because it records hosted decisions when OIDC is available and falls back to labelled evidence-only reporting instead of blocking adoption.

APort reports newly added id-token: write as a warning, not as repository write escalation. OIDC lets the workflow ask GitHub for an identity token; it does not let the workflow mutate repository contents. Broad permissions such as write-all, contents: write, actions: write, and pull-requests: write are still high-severity structural findings.

What should block first

Do not start by blocking everything. Start with high-confidence denies.

Good first blockers:

• evidence is incomplete for a protected path change;
• workflow patch is unavailable;
• a workflow introduces pull_request_target;
• a workflow expands write permissions;
• a policy file is changed in the same untrusted PR;
• a release publish request has no valid signed decision.

Good first warnings:

• lockfile changed;
• package manifest changed;
• unpinned action introduced;
• protected path touched by an attributed agent;
• large PR with many files.

This creates a path from audit to enforcement without breaking normal engineering work.

Why this matters for supply-chain security

AI coding agents increase the speed of code change. That is the benefit. It is also the risk.

The same agent that updates a feature can accidentally update a workflow. The same prompt that fixes a bug can accept a poisoned package suggestion. The same automation that saves time can publish a release with insufficient context.

APort does not replace GitHub branch protection, dependency scanning, code review, or secret scanning. It adds the missing layer:

a signed policy decision tied to the agent or workflow before the repository change is trusted.

That is how GitHub Actions security becomes AI-agent-aware.

Start with one workflow

Start free with report-only checks on one repository, then upgrade to APort Team
when you want hosted signed decisions to fail unsafe checks through branch
protection. Use Enterprise when the same control needs to roll out across
multiple repositories and developer devices.

• Add GitHub Repository Guard
• See APort Team and Enterprise pricing
• Review enterprise deployment