Security coverage

Pushgate mapped against the OWASP Top 10 for Agentic Applications, honestly.

Short version: Pushgate substantially addresses two of the ten risks, meaningfully contains six, and does nothing for two. Stable per-agent identity is still a contract target, so Identity and Privilege Abuse belongs in containment today rather than the substantial column. The argument is not that Pushgate replaces the gateway, the sandbox, or the identity layer — it is that one entire class of agentic risk has no other layer covering it at all.

Why the honest answer is a partial one

Pushgate is a control at one boundary. It sees what an agent tried to commit, who or what pushed it, and the evidence bound to that commit. It never sees the agent's context window, its retrieved documents, the tools it called that did not touch git, or its conversations with other agents.

That boundary determines everything about coverage. For most of the ten risks, the gate does not prevent the agent from being compromised. It prevents the consequence from reaching the trunk, and it produces evidence that the attempt happened. Those are different claims and they should be kept apart:

• Prevention — the failure cannot occur.
• Containment — the failure occurs but cannot propagate past the gate.
• Evidence — the failure is recorded whether or not it was blocked.

Pushgate delivers containment and evidence almost everywhere, and prevention in a few specific places. That is still a strong position, because containment at a chokepoint is what turns an unbounded agent failure into a bounded one.

The scorecard

Where the coverage is real

ASI03 — Identity and Privilege Abuse

OWASP's mitigations for this entry ask for per-agent identities, short-lived credentials, task-scoped permissions, and no privilege inheritance across agents. Pushgate implements part of that shape today: every signed push carries a short-lived certificate naming its signing principal, and repository-federated token issuance constrains which credential can reach the repository route. Current built-ins can require a trusted platform signature, but they do not generally allowlist a stable agent UUID by repository, branch, or path. Repository setup and service-federation credentials are separate, longer-lived, purpose-scoped credentials, so the short-lived certificate must not be advertised as the absence of every inheritable credential. A stable server-derived agent UUID and its projection into policy and receipt provenance remain required for a complete per-agent identity claim.

Evidence available today: git, github, gitlab, jwt, and the CI-context attestors covering the major CI platforms.

ASI04 — Agentic Supply Chain

The strongest fit, and the one worth leading with. An agent that writes code writes dependencies, and dependency hallucination is the failure mode nobody catches by reading the diff: models emit imports for packages that do not exist, adversaries register those names, and the resulting code compiles and passes tests while pulling in adversary-controlled source. Human review does not catch it because the import looks idiomatic.

A gate whose policy requires every dependency to resolve to an approved source with attestation catches it structurally. This is the case where the control is genuinely preventive rather than merely containing.

Evidence available today: lockfiles, npm-install, pip-install, yarn-install, pnpm-install, maven; SBOM generation via syft, cdxgen, bom, sbom; verification via cosign-verify; advisory matching via osv-scanner, grype, trivy, npm-audit, pip-audit, cargo-audit, yarn-audit, nancy, retire-js; exploitability context via vex and vexctl; and malcontent for malicious-code detection in dependencies.

ASI10 — Rogue Agents

Read OWASP's own mitigation list for this entry and much of it describes a gate. It asks for immutable signed records, per-agent cryptographic identity, ephemeral audience-bound credentials, and revocation. Pushgate currently covers the Git boundary with keyless signing and purpose-scoped repository credentials; it does not record arbitrary agent actions, and stable per-agent identity plus the complete final receipt remain follow-ups. Keyless signing still provides an important property: the signing key exists for one signature and is discarded rather than becoming a long-lived secret an agent can exfiltrate.

What a gate does not provide is the behavioural side of ASI10 — challenge tasks and continuous runtime verification against a declared manifest. Policy is a static manifest, not a behavioural one.

Where it contains rather than prevents

ASI01 — Agent Goal Hijack

The gate cannot see a hijacked goal. What it can do is require independently signed test and scan evidence and, where configured, a snapshot showing that GitHub recorded an approval by a named account. That review state does not prove a person was present: an account token or bot can create it. An agent redirected to inject a backdoor still has to satisfy the exact configured evidence rules, but the assurance is no stronger than each producer and signing identity.

Worth noting that OWASP's own suggested mitigation here is an "intent capsule" binding the declared goal, constraints, and context into a signed envelope. That is a DSSE envelope with a different predicate. The mechanism already exists; only the predicate is unwritten.

Evidence available today: github-review, go-test, pytest, jest, test-results, semgrep, codeql, gosec, bandit, staticcheck.

ASI02 — Tool Misuse and Exploitation

Git is one tool, and the gate constrains it completely. Every other tool an agent reaches for is outside its view. The command-run attestor records the command that was invoked during a build and its exit code, which narrows the gap but does not close it — it does not capture the full process tree, so a pinned command can be bypassed through indirection. Honest framing: this is one tool secured, not tool use governed.

ASI05 — Unexpected Code Execution

An agent that achieves code execution in its own sandbox is not stopped by anything at the git boundary. What the gate stops is the resulting change becoming part of the codebase. That distinction matters because the documented incidents in this category — a coding agent destroying production infrastructure, another wiping a database and its snapshots — did not travel through a git push, and a push gate would not have prevented either. Deploy-time admission control is the answer to those, not this.

ASI08 — Cascading Agent Failures

When one agent's output becomes another agent's input through the repository, the gate is a circuit breaker in that path. A bad change that cannot land cannot be picked up downstream. Where agents pass state to each other directly, the gate is not in the path and offers nothing.

ASI09 — Human-Agent Trust Exploitation

The specific exploit of a human accepting an agent's assurance that something was tested is narrowed by signed test evidence. A GitHub-review attestation makes the recorded API state and reviewer account checkable, but it must be labeled as an observed account action rather than proof of a human review. Verified human presence requires a separate server-observed ceremony, with recent reauthentication or WebAuthn if that assurance matters.

Where it offers nothing, and saying so

ASI06 and ASI07. Memory and Context Poisoning happens entirely upstream of the gate. Poisoned retrieval, contaminated long-term memory, and an agent re-ingesting its own output into trusted storage are all invisible from git. The gate is a backstop only in the sense that poisoned memory producing bad code still faces the same output controls, which is thin comfort and should not be presented as coverage.

Insecure Inter-Agent Communication is a transport and authorization problem between running agents. A git-boundary control has no visibility into it and no mechanism to affect it.

These two need runtime controls — workload identity, mutual authentication between agents, and memory provenance. They are a different product, and pretending otherwise in front of a security team costs more credibility than the admission does.

Where Pushgate sits among the other defences

A push gate is one layer, and it is not the layer most people reach for first. That is the correct instinct — the other layers exist because they work, and none of them is displaced by this one. What follows is an honest comparison rather than a pitch, because the interesting result is not that the gate wins anywhere. It is that one risk has no other layer at all.

The five layers, and what each can actually see

The first four all sit upstream of the artifact, and they share a property worth naming: they are probabilistic or observational. A prompt-injection detector has false negatives. A sandbox limits blast radius without judging whether the code is right. Monitoring needs a baseline and reports after the event. Each is valuable, and none of them produces a durable, verifiable record bound to the thing that ultimately matters, which is the code that lands.

The gate is the one layer that is binary and evidentiary. It either satisfies policy or it does not. The signed-decision rollout makes real policy allow and deny results durable; infrastructure or trust failures remain unsigned, and the final delivery receipt is not yet generally available. Put crudely: the first four layers protect the agent. The fifth protects the codebase.

Coverage by layer

Reading: ● primary control, ◐ partial or containment, ○ nothing.

Read the ASI04 row. Every other risk has at least two layers contributing something. Agentic Supply Chain has exactly one. A gateway does not see a dependency being added. A sandbox happily executes an install of an adversary-controlled package. An identity system authorises the agent that pulled it. Monitoring sees a normal-looking build. The hallucinated import survives all four and lands in the tree.

That is the hole. It is not that the artifact boundary is a better place to enforce than the others — it is that until now nobody was enforcing there at all, and one entire class of agentic risk falls through as a result.

What this means for how to deploy

Nothing here argues for the gate instead of the others. An organisation running only a push gate is still exposed to prompt injection, still lets an agent destroy infrastructure through tool calls, and still cannot see its agents talking to each other. Those need L1, L2 and L3 respectively, and the two risks this page marks as uncovered are covered elsewhere in the stack.

The sensible reading is the reverse. An organisation running a gateway, a sandbox, an identity layer and monitoring has a mature agentic security posture and still has no control on what reaches the repository, and no cryptographic record of what produced it. That is a narrow gap, but it is the one that ends up in production.

Attesting what produced the code

The attestor catalog covers the build and dependency surface thoroughly — more than 130 attestors. The question agentic development adds is different: which authenticated principal signed the evidence or policy, what agent process context was visible, and which human accepted an exact repository assignment. Those are three separate claims.

Pushgate understands agent-context evidence for the observational part of that question; its first-party Cilock producer is still being integrated. When such evidence is present, the gate displays the coding-agent process context visible when it was collected, bound to the commit like any other attestation. It observes; it never gates. A same-user process can influence the product, model, and configuration it reports, so the record neither authenticates a stable agent principal nor proves what the agent did outside that context. Policies and reviewers should treat it as declared/observed context, never as evidence of an agent's absence, identity, or good behaviour.

The wider ecosystem is still catching up:

• SLSA v1.2 has no AI coverage at all; a proposal for AI agent levels was closed in April 2026 on the grounds that build provenance already overlaps too much.
• CycloneDX's model card has been frozen since 1.5, and the OpenSSF model signing predicate carries a file manifest and nothing else — model integrity rather than model provenance.
• C2PA 2.4 (April 2026) did specify an AI disclosure assertion — model type, model name, a model identifier as a package URL, and a humanOversightLevel field — plus embedding into source code as a comment line referencing an external manifest. The reference implementation contains no support for that assertion: it is specified, not implemented.
• in-toto has had an issue open for AI-assisted code attestation since June 2023, and a predicate for AI agent actions proposed in August 2026 remains open.

A richer predicate — carrying model identity and version, the policy or system prompt revision in force, the agent identity that invoked it, the human who accepted it, and the diff attributed to the agent — is planned. Two viable vehicles exist today: the C2PA assertion above, which has the vocabulary but no implementation, or in-toto SCAI v0.3, which is vetted, deliberately domain-agnostic, and shipping. The machinery is built either way; what is missing is the predicate definition and the attestor fields that emit it.

A trap in any policy that cites SLSA

First, a distinction that trips people up: in the current specification, v1.2, the Build track stops at Build L3. Build L4 existed in the v0.1 draft and was removed in v1.0. The Source track, which is the newer of the two, does define four levels, and Source L4 is the one that matters here.

Source L4 requires two-party review, but it also permits an organisation to grant a Trusted Robot a perpetual exception to that policy. The specification's own examples are import and migration bots and Dependabot. If an organisation classifies an AI coding agent into that class, Source L4 quietly stops meaning that two humans looked at the change, while the badge stays the same.

Any policy relying on Source L4 should exclude AI coding agents from the Trusted Robot class explicitly. Worth noting separately that SLSA deliberately leaves source provenance predicates undefined, so the predicate is being specified locally in any case.

Summary for a reviewer

Two of the ten are substantially addressed: supply chain and rogue-agent containment at the Git boundary. Six are contained rather than prevented, including identity until stable per-agent principals ship. Two are out of scope and need runtime controls instead.

The one gap worth acting on is not in the coverage of existing risks. It is provenance of authorship: recording, verifiably, what produced the code. Pushgate can display observational agent context today; its first-party producer, a stable server-derived agent principal, and a receipt that separately binds artifact signer, human activation actor, and delivery observer remain the richer provenance contract. Unusually, the specification groundwork for that contract already exists in the ecosystem.

Risk taxonomy: OWASP Top 10 for Agentic Applications, 2026 edition. Attestor names are from the platform attestor catalog.