"Agent Authorization: The Missing Control Point in AI-Assisted Software Delivery"

Every engineering organization that has deployed AI coding agents at scale eventually hits the same question: how do we reliably know which changes were agent-authored, who authorized them, and whether we can safely reduce manual review without increasing operational risk?

The default answer today is mandatory human review for nearly every pull request that might involve an agent. This is safe but expensive. It caps the economic return of coding agents at roughly the cost of the humans reviewing their output. A dashboard that shows agent activity is helpful for awareness but does not control the consequential action. An audit log tells you what happened after the fact, which is too late for the merge decision. And vendor-specific controls from GitHub, GitLab, or Cursor do not compose into a unified authorization layer that works across coding agents, repositories, and policy domains.

There is a missing control point in the AI-assisted software delivery pipeline. This whitepaper defines it and explains why getting it right determines whether enterprises adopt AI coding agents at scale or leave the productivity gains on the table.

The Five Questions No One Can Answer at Merge Time

When an AI coding agent contributes to a pull request, the merge decision depends on five questions that most engineering organizations cannot answer with confidence.

One, who or what produced this change? Was it a human, an agent, or a mix of both? Two, which human authorized the agent's work? Is there an accountable sponsor? Three, what evidence exists that this change is safe? Has it passed the required checks, reviews, and compliance gates? Four, which policy governed this decision, and was the same policy applied consistently to similar changes? Five, what happened after this change was released? Did it succeed, fail, or get reverted?

These questions determine whether a platform team can safely delegate more authority to agents, whether a security team can demonstrate control during an audit, and whether an engineering organization captures the productivity gains of AI-assisted development without accepting unacceptable operational risk.

The current approaches all fall short. GitHub's enterprise agent management exposes session metadata and policy controls, but those controls are GitHub-specific and do not compose across multiple coding agents or repository hosts. Cursor's AI Code Tracking API provides attribution signals, but absence of Cursor evidence does not mean the change was human-authored. Jira provides work-item context for intent and sponsorship, but Jira is not connected to the authorization decision. Audit logging records what happened but does not prevent the merge. And dashboards report aggregate statistics but cannot block an unauthorized change.

Each of these tools solves one piece of the puzzle. None of them provides an independent, verifiable, cross-provider authorization decision at the merge boundary with signed evidence that can survive an audit.

The Thesis: Independent Authorization with Deterministic Policy

TrustRelay is built on a specific hypothesis: platform and security teams will allow an independent authorization layer to replace some mandatory manual review for low-risk, agent-authored pull requests when it provides reliable attribution, required evidence, a reproducible policy decision, an understandable explanation, and a customer-controlled recovery path.

This is not a thesis about dashboards, reports, or visibility. It is a thesis about authority. A dashboard that shows you that an agent-authored change was merged without review is useful for post-incident analysis but does not prevent the incident. An audit log that tells you which agent contributed to a change is valuable for forensics but does not help you decide whether to approve the merge. An independent authorization layer that sits at the merge boundary, evaluates evidence against deterministic policy, and issues a signed, verifiable decision before the merge happens is a fundamentally different class of control.

The key word is independent. TrustRelay is not a coding agent. It is not a source-code host. It is not a CI/CD platform. It is a neutral authorization layer that observes agent-authored changes, assembles evidence from multiple sources, applies the customer's policy, and produces a signed decision that can be independently verified by any party. This independence is not a marketing distinction. It is an architectural guarantee.

Why Deterministic Matters

The decision engine is a pure function. Given the same policy version, evidence snapshot, attribution assertions, and repository metadata, it always produces the same decision. There is no model inference, no heuristic weighing, no learned behavior. The decision is not a prediction or a recommendation. It is an evaluation of evidence against rules, and it is fully reproducible.

This is a deliberate architectural choice rooted in the safety requirements of the control point. An authorization decision that permits or prevents a software change from merging is consequential. It must be testable, explainable, and verifiable under adversarial conditions including model failure, prompt injection, provider outage, and operator error.

The deterministic constraint applies at every level. AI-assisted components may propose typed assertions about agent identity, change classification, or confidence scores. Those assertions carry source qualification, confidence metadata, and evidence references. But they do not make or modify the authorization decision. Invalid, unsupported, unavailable, timed-out, stale, low-confidence, or conflicting assertions produce a non-success state. No ambiguity becomes permission. This is not a performance optimization. It is a safety invariant.

The practical implication is that every decision can be replayed from a stored evidence snapshot against the same policy version and produce an identical result. This is essential for audit, for regression testing, for incident investigation, and for building trust with platform teams who need to understand exactly why TrustRelay made the decision it did. A model whose outputs shift with each deployment cannot provide this guarantee. A deterministic engine can.

Designed for the Merge Boundary

TrustRelay's architecture follows from the requirements of the control point. The system observes a pull request at an exact revision, establishes agent attribution and human sponsorship, assembles a versioned evidence snapshot, applies deterministic policy, and issues one of three decisions: APPROVE, BLOCK, or ESCALATE. Each decision is accompanied by a stable reason code, a list of evaluated rules, a record of missing evidence, and a canonical decision hash. The decision is signed by AWS KMS and stored in an S3 ledger with WORM protection. A signed Agent Change Passport is issued as an independently verifiable artifact. A GitHub required check reports the outcome to the pull request. Overrides and production outcomes are preserved as linked supplements without rewriting history.

The system is decomposed into independent services, each with its own CI/CD pipeline, IAM role, and release cadence. This is not an aesthetic choice. The decision engine has fundamentally different operational requirements from the evidence pipeline or the enforcement layer. The decision engine must be independently verifiable, replayable, and auditable with zero runtime dependencies on network services. The evidence pipeline is I/O-bound and integration-heavy. The enforcement layer is latency-critical and touches the GitHub API on every request. These profiles should not share a deployment envelope.

The decision engine itself is a pure TypeScript function with no imports from AWS SDK, database drivers, network clients, model SDKs, or Secrets Manager. Architecture tests enforce this boundary at the CI level. This means the decision engine can be deployed independently, tested in isolation, and verified by third parties who do not need access to the broader infrastructure. It is the part of the system that must earn the most trust, and it is designed to be as small and auditable as possible.

Evidence is collected from multiple sources and normalized into a sealed Evidence Snapshot that is hashed and stored before the decision is made. The snapshot includes attribution signals from coding-agent providers, commit metadata from GitHub, work-item context from Jira, CI status from connected pipelines, and repository risk context from the customer's service catalog. The snapshot is versioned and immutable after sealing. If new evidence arrives after a decision, the system evaluates again against the new snapshot, preserving the original decision as a historical record.

The signed Agent Change Passport is the integrity artifact that makes all of this independently verifiable. The passport contains the policy version, the evidence snapshot hash, the attribution assertions, the decision and reason codes, and the KMS signature. Anyone with the passport and access to the verifying public key can confirm that the decision was made by TrustRelay's signing key against the claimed evidence and policy. No database access is required. No API call is needed. The passport is self-verifying.

The Network Effects That Compound With Every Decision

A common question about independent authorization is why it cannot simply be absorbed as a feature of the source-code host or the coding-agent vendor. The question is worth taking seriously because it tests whether the product is durable or temporary.

The answer has five layers, and each one compounds with use rather than diminishing.

First, the Organizational Change Risk Graph. Every authorization decision produces structured data about which services, repositories, agents, and policies interact. Over time and across thousands of decisions, this produces a normalized risk graph specific to each customer that captures the relationships between services, their criticality, and their authorization history. This graph is tenant-private and cannot be replicated by a source-code host that only sees one repository at a time or a coding-agent vendor that only sees its own telemetry.

Second, the Agent Change Outcome Corpus. With customer consent and privacy-preserving aggregation, TrustRelay can learn across customers which types of changes, policies, and evidence patterns correlate with successful outcomes. A coding-agent vendor sees its own telemetry. TrustRelay, sitting at the merge boundary across agents and repositories, sees the full decision-to-outcome loop. This cross-customer signal improves every customer's policy precision over time.

Third, required enforcement embedded in merge workflows. A dashboard is a feature that can be replaced by a competitor's dashboard. A required GitHub check that blocks the merge unless TrustRelay approves is an architectural control embedded in the customer's delivery pipeline. Once a customer configures TrustRelay as a required check on their most important repositories, replacing it means changing merge policy, updating branch protection rules, and reconfiguring every repository that depends on it. That is a higher-friction decision than turning off a dashboard.

Fourth, integration depth. TrustRelay connects to GitHub, Jira, multiple coding-agent providers, CI/CD pipelines, and eventually deployment platforms. Each integration provides evidence signals that improve decision quality. The network effect is that the system's decisions improve as it integrates with more of the customer's toolchain, and the cost of replacing it increases with each integration. This is the opposite of a feature that degrades with use.

Fifth, independent trust as a compounding asset. An authorization platform that must be trustworthy across agents, repositories, and cloud boundaries earns its reputation through reliability, explainability, and evidence discipline over time. This trust is earned one decision at a time, and it is not transferable to a vendor that is also the thing being authorized. A coding agent vendor cannot credibly claim to independently authorize its own agent's output. An independent platform can, and that credibility compounds with every correctly handled decision and every transparently explained escalation.

The Validation Test: Enforcement Delegation

The most important test for independent authorization is not whether a customer generates passports, views dashboards, or runs in shadow mode. It is whether a customer delegates real merge authority to the platform. Advisory-only interest is necessary technical progress but insufficient market proof. The product hypothesis is validated only when a customer configures TrustRelay as a required check and allows it to block real changes.

This is why TrustRelay's pilot model is designed around staged authority. A pilot begins in shadow mode, where the system observes and reports but does not block. The customer reviews decisions, examines evidence, and builds confidence. The pilot then transitions to advisory mode, where the system reports what it would have done but enforcement remains manual. The final stage is limited enforcement on a defined repository envelope, where TrustRelay publishes a required check that must pass before the PR can merge.

The transition from shadow to enforcement is the validation event. It is the point at which the customer's platform team says, in effect, we trust this independent system to make an enforceable authorization decision on our behalf. Every pilot before that transition is a technical exercise. The first required-check deployment is a product validation.

This staging exists not because the technology needs to be tested but because the trust relationship needs to be built. Platform teams need to see TrustRelay operate on their actual repositories, with their actual policies and agent configurations, before they delegate authority. The evidence snapshot, the deterministic decision engine, the signed passport, and the override path all exist to make that trust relationship possible.

What Happens If the Thesis Is True

If platform teams do delegate merge authority to an independent authorization layer, the implications extend beyond the merge decision. An authorization platform that sits at the merge boundary and captures the full decision-to-outcome loop becomes the foundation for a richer understanding of software delivery risk.

The same evidence pipeline that determines whether a PR can merge can also feed deployment authorization policies. The same risk graph that captures service criticality for authorization can inform incident response prioritization. The same outcome corpus that tracks whether approved changes succeed or fail can produce increasingly accurate policy recommendations over time.

These are expansions, not the MVP. The MVP is one reliable loop through one merge boundary. But the architecture is designed for a compounding trajectory: each authorization decision improves the risk graph, each outcome strengthens the outcome corpus, and each integration deepens the network effects. The product earns the right to expand by proving the first control point.

Conclusion

The adoption of AI coding agents is not slowing down. GitHub Copilot, Cursor, and other agents are writing an increasing share of production code. The question is not whether agent-authored changes will dominate software delivery but whether enterprises can adopt them safely. The current answer, mandatory human review for everything, caps the productivity gain. The alternative, trusting agent vendors to self-govern, creates an accountability gap that no audit log can close.

Independent, deterministic authorization with signed evidence is the missing control point. It is not a dashboard, an audit trail, or a vendor-specific feature. It is a neutral authorization layer that sits at the merge boundary, evaluates evidence against customer policy, and produces a signed, verifiable decision that any party can independently confirm. It is designed for the safety requirements of the control point: deterministic, testable, explainable, and recoverable.

The thesis is testable. It will be validated or refuted by whether customers delegate enforcement authority, not by whether they consume reports. That is the right standard for a product that sits at the boundary between agent productivity and production safety. TrustRelay is building toward that standard, one merge decision at a time.