Security coverage

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

Short version: Pushgate substantially addresses three of the ten risks, meaningfully contains five, and does nothing for two. Claiming more than that would not survive a technical review. The argument is not that it 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. A keyless push gate is close to a direct implementation. Every push carries a certificate whose subject names the pushing identity, the certificate lives minutes rather than indefinitely, and policy constrains which identity may write to which repository, branch, or path. There is no long-lived credential for an agent to inherit, leak, or reuse outside its scope.

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 most of it describes a gate. It asks for immutable and signed audit logs of agent actions, per-agent cryptographic identity attestation, ephemeral credentials with one-time audience binding, and kill switches with credential revocation. It also states the requirement that matters most: that keys must never be directly available to agents, and that signing be mediated so a compromised agent cannot exfiltrate a long-lived key. Keyless signing satisfies that by construction: the key exists for the duration of one signature and is discarded.

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 evidence the hijacked agent cannot fabricate: a human review attestation naming a real reviewer, tests that actually ran and passed, scans that came back clean. An agent redirected to inject a backdoor still has to produce a commit that satisfies all of those, and it cannot forge them without also compromising the identities that sign them.

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 reviewed or tested is answered by making those claims verifiable rather than asserted. A review attestation names a human identity and is signed; "it was reviewed" stops being a sentence in a pull request description and becomes a checkable fact.

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, and either way the decision is signed and kept. 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 agent, under which conditions, produced this change, and which human accepted it.

Pushgate ships an agent-context attestor for the first part of that question. It records which coding agent produced a push, bound to the commit like any other attestation. It observes; it never gates. And the record is observational, not hermetic: it documents the agent context that was visible when the push was made, and it does not prove what the agent did or did not do outside that record. Policies and reviewers should treat it as a recorded fact about the push's context, never as proof of an agent's absence 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

Three of the ten are substantially addressed, and they are the three that are structurally hard to solve elsewhere: identity, supply chain, and rogue agent containment. Five are contained rather than prevented, which is the correct outcome for a boundary control and still converts unbounded failures into bounded ones. 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's agent-context attestor records the agent that made the push today; the richer authorship predicate is planned, and unusually, the specification groundwork for it already exists in the ecosystem.

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