Code-Generation Agents In Regulated Industries: SOC 2, FedRAMP, And The Provenance Pipeline

TL;DR

Code-generation agents in regulated environments operate under controls regimes that did not anticipate them. SOC 2 expects evidence of access control over change management. FedRAMP expects authorized parties to be the change agents and authorized processes to be the change pipeline. Both expect every modification to production code to be traceable to an identifiable principal acting under documented authority. An agent that opens pull requests against your repository satisfies none of this by default. The auditor will ask who wrote line 247 of file X, under what authority, evidenced by what artifact, and the answer cannot be the agent committed it. The answer has to be the agent acted under pact P, against approved scope S, in run R, with evidence E, reviewed by human reviewer H. This post is the structure of the provenance pipeline that produces that answer at scale, the changes it requires in your existing CI, and the artifact format auditors will accept.

The audit finding that paused a Series C company's revenue for nine weeks

In April of last year a Series C software company that sold into US federal civilian agencies received their FedRAMP Moderate authorization, after eighteen months of preparation and several million dollars of compliance spend. The authorization was the gate to a multi-million-dollar contract with a federal customer that was to begin the following quarter. In May the company's engineering organization, encouraged by the productivity gains they had been seeing in their non-regulated work, deployed an agent-based code-generation system into their main production codebase. The system opened pull requests, ran tests, addressed reviewer feedback, and merged with human approval. By July it was producing roughly 30 percent of the company's commit volume.

In August the company's first FedRAMP continuous monitoring assessment began. The assessor, working through the system change history, asked a routine question about a particular pull request that had landed in early July. The pull request had been merged by a human engineer after two rounds of review, the diff was small, the test coverage was strong, and there was no obvious issue with the change itself. The assessor's question was who wrote it. The engineering lead explained that the agent had drafted the change in response to a ticket, the agent's commit author was a service identity associated with the agent's deployment, and the human engineer had reviewed and merged. The assessor asked for the agent's authorization to make changes to the codebase, the documented scope of the agent's authority, the policy that governed the agent's behavior, and the audit trail of the agent's reasoning for that specific change. The engineering lead did not have any of these.

The assessor escalated. Over the next two weeks the company produced a series of artifacts that did not satisfy the assessor's questions. The agent's deployment had been documented at the system architecture level but not at the change-management level. The agent's commits all carried the same service identity, with no record of which agent instance had produced which commit, which prompt had been used, which model version had generated the code, or which inputs had informed the generation. The reviewer's approval was documented in the pull request system, which was the company's existing change management evidence, but the artifact the reviewer had reviewed was the diff, not the agent's reasoning chain or the agent's source citations or the agent's confidence in the change. The assessor concluded that the company's change management controls had been implemented for human authors and were not satisfied for the agent's authorship pattern.

The finding was a moderate-severity control deficiency. The company was given a remediation window. The company also had to disclose the finding in its responses to ongoing federal procurement processes, which delayed the federal contract by nine weeks while the customer's procurement team evaluated the risk. The remediation involved building a provenance pipeline retroactively, documenting every commit the agent had made, identifying the prompts and runs and reviewers for each, and producing the kind of audit trail the assessor would accept. The remediation cost was substantial, the contract delay was the more painful loss, and the company's leadership decided that the agent could not operate in any regulated codebase until the provenance pipeline was built and operating in advance of any future commits.

This is the canonical regulated code-generation failure mode. The agent works fine. The code is good. The reviews happen. The tests pass. The deployment succeeds. The audit fails because the controls regime requires a level of authorship traceability that the default agent deployment does not produce. The fix is not to stop using agents. The fix is to build the provenance pipeline as a first-class part of the agent's deployment, with the same engineering investment as the agent itself, and to design the audit trail against the questions the assessor will ask rather than against the questions the engineering team thinks are interesting. The rest of this post is the structure of that pipeline.

H2 1: What SOC 2 and FedRAMP actually require

SOC 2 and FedRAMP are different regimes with different scopes, but their change management requirements have substantial overlap that is useful to articulate before designing the provenance pipeline. The overlap is the set of properties the auditor will look for, and the differences are in the depth and the rigor with which the properties have to be evidenced.

SOC 2's relevant criteria sit in the Common Criteria for change management and in the system development criteria when applicable. The auditor expects that changes to the production environment are authorized, that the authorization is documented, that the change is tested, that the change is reviewed by a party other than the developer when applicable, that the change is documented post-implementation, and that the records are retained. The auditor will sample changes from the period under review and trace each one through the controls. A sample change has to have an authorization record, a test record, a review record, and a documentation record, and the auditor expects to see them in a coherent trail.

FedRAMP's requirements are more elaborate and they sit primarily in the Configuration Management family of NIST 800-53. The relevant controls include CM-3 for configuration change control, CM-4 for security impact analysis, CM-5 for access restrictions for change, and CM-9 for the configuration management plan. The assessor will look for documented authorization for each change, evidence of security impact analysis, evidence that the change was made by an authorized party using authorized processes, and evidence that the change was tested and approved before deployment. The assessor will sample changes and trace each through the entire control set, with deeper attention to changes that touch security-relevant code, that affect the system boundary, or that change the authentication, authorization, or audit subsystems.

The overlap is the set of properties the auditor wants to see for every sampled change, regardless of the regime. Property one, identification of the principal who initiated the change. Property two, documentation of the principal's authority to make that change. Property three, the artifacts that informed the change. Property four, the testing the change underwent. Property five, the review the change received and the identity of the reviewer. Property six, the deployment record. Property seven, the post-implementation documentation. The agent has to satisfy all seven for any commit it makes, and the satisfaction has to be visible in a coherent trail that the auditor can follow without engineering assistance.

The difficulty for code-generation agents is that the seven properties are typically distributed across the version control system, the CI/CD pipeline, the issue tracker, the deployment system, and any number of internal documents. For a human author the trail can be reconstructed through these systems because the human's identity is consistent across them and the human's work is visible in the artifacts. For an agent the trail typically does not exist because the agent's work is not anchored to a stable identity in each system, the agent's reasoning is not retained anywhere the auditor can find it, and the agent's authority is asserted at the system level but not invoked per change. The provenance pipeline is the structure that makes the trail exist for every commit, with the same coherence the auditor expects from a human author.

The pipeline is also the structure that scales with agent throughput. A regime that worked for a hundred human-authored changes per month does not necessarily work for ten thousand agent-authored changes per month, even if the per-change provenance is in place. The pipeline has to produce structured, queryable, and indexable provenance records, not human-readable narratives, because the auditor's sampling is going to query against the records and the engineering team's response time depends on whether the records are in a queryable form. Auditors who have grown comfortable with the pipeline will sample more efficiently, the engineering response cost will be lower, and the relationship between the company and the assessor will be substantially better than the relationship that produces the nine-week contract delay.

H2 2: The pact as the agent's documented authority

The agent's documented authority to make changes is the foundation of the provenance pipeline. The default deployment of a code-generation agent typically asserts the authority at the system level, the agent has access to the repository because it has been granted credentials. This is operationally true and audit-insufficient. The auditor wants to see authority at the change level, not at the system level. The agent should have authority to make a particular kind of change in a particular part of the codebase under particular conditions, and the authority should be documented in advance and applied per change.

The pact is the artifact that documents the per-change authority. A pact for a code-generation agent specifies the repositories the agent can touch, the paths within each repository the agent is allowed to modify, the kinds of changes the agent can make, the categories of code that require additional review, the maximum scope of any single change, the testing requirements before merge, the reviewer requirements, and the security-impact-analysis requirements for changes that touch security-relevant code. The pact is signed by the company's authorized officer, hashed, and anchored on Base L2 through the trust layer's audit anchor. The pact is queryable and the auditor can verify that the pact existed, when it was signed, by whom, and what scope it authorized.

The pact is per-agent, not per-vendor. A single vendor might supply multiple agents with different scopes, and each agent has its own pact. An agent that is authorized to refactor non-production code under a permissive pact does not have authority over production-deployed code unless a different pact is in place. The agent's scope cannot expand silently, because the agent's authority is checked at every action against the pact in effect for that agent. A change that exceeds the pact's scope is not made by the agent, it is escalated for human authorization or for pact amendment.

The pact's scope is precise. A pact might authorize the agent to modify files matching a glob pattern in the test directory, to modify documentation in the docs directory, to add or modify imports in source files, to write new test cases, but not to modify the test runner configuration, not to modify the security middleware, not to modify the authentication code, not to add new external dependencies. The exclusions are explicit and the agent's authorization gate enforces them by inspecting the diff against the pact's exclusions before the agent commits. A change that touches an excluded path is rejected at the gate.

The pact also specifies the reviewer requirements per change category. A change in the test directory might require one reviewer with general engineering authority. A change in the API surface might require two reviewers, one with general authority and one with API-design authority. A change in the security middleware might require a reviewer with security authority and a separate security impact analysis. The pact maps change categories to reviewer requirements, and the agent's pull request structure carries the categorization so that the review system can route the request appropriately.

The pact is renewed periodically, typically quarterly or semi-annually, and the renewal is when the agent's authority is reviewed against its operating record. An agent that has performed well over the period might have its authority broadened, with the corresponding documentation update. An agent that has had problematic changes might have its authority narrowed. The renewal cycle is what keeps the agent's authority aligned with the company's actual risk tolerance, rather than freezing the authority at the level it was granted at deployment.

H2 3: The per-commit provenance record

The per-commit provenance record is the artifact the auditor will inspect for any sampled change. The record is structured, machine-readable, and stored alongside the commit in a system that the auditor can access through a defined query interface. The record is not optional, every commit the agent makes has to have one, and a commit that is missing its provenance record is rejected at the merge gate.

The record's required fields are the seven properties from the auditor's checklist, expressed in a structured form. Field one is the principal identifier, which for an agent is the agent's unique identity, the agent's certification tier at the time of the commit, and the run identifier under which the commit was generated. The principal identifier is not the agent's service account on the version control system, that account is the technical identity used to push the commit. The principal identifier is the trust-layer identity that allows the auditor to look up the agent in the trust oracle and verify its certification status.

Field two is the authority reference, which is the pact identifier and version under which the commit was made. The reference allows the auditor to query the pact and verify the scope, the reviewer requirements, and the testing requirements that applied to the commit. Field three is the inputs that informed the change, which is the issue or ticket the change responded to, the prior commits that were used as context, the documentation references, the conversation transcript with any human collaborators, and the reasoning chain the agent produced. The inputs are stored verbatim, not paraphrased, because the auditor needs to be able to reconstruct what the agent had access to.

Field four is the test record, which includes the tests the agent ran before opening the pull request, the tests CI ran on the pull request, the coverage delta, and any test failures the agent addressed. Field five is the review record, which includes the reviewers, their identities, their reviews, any review iterations, and the final approval. Field six is the deployment record, which is added at the time of deployment and includes the deployment identifier, the deploying party, and any deployment-time validation. Field seven is the post-implementation documentation, which includes any release notes, any monitoring alerts the change generated, any subsequent issues that referenced the change, and the audit-trail anchor that links the record to the chain.

The seven fields together produce the coherent trail the auditor expects. A sampled commit can be looked up, its principal identified, its authority verified, its inputs reviewed, its tests checked, its review confirmed, its deployment traced, and its post-implementation documentation read. The auditor's question of who wrote it has a structured answer, the agent identified by ID, acting under pact P version V, in run R, with the reasoning visible in the inputs field. The auditor's follow-up questions about authority, testing, and review all have structured answers in the same record. The provenance pipeline produces this for every commit without engineering intervention.

The storage of the records is itself part of the audit. The records are stored in a system that the auditor can access through a defined query interface, with appropriate access controls and retention. The records are anchored to the audit chain through periodic Merkle batches so that the records cannot be edited after the fact without detection. The retention is for at least the regime's required period, typically seven years for SOC 2 and longer for FedRAMP, and the storage is replicated and backed up against any single-system failure.

H2 4: The reasoning chain as auditable artifact

The reasoning chain is the part of the inputs field that requires the most attention because it is the artifact most distinctive to agent authorship and most important for security impact analysis. The reasoning chain is the structured trace of how the agent moved from the input ticket through the code analysis to the change. It is not a paraphrase. It is a verbose, machine-readable record that can be replayed by an evaluator to verify that the agent's reasoning was sound.

The reasoning chain has to capture several things explicitly. The agent's interpretation of the ticket, including which acceptance criteria the agent identified and which it did not. The agent's investigation of the codebase, including which files the agent read, which symbols the agent looked up, which tests the agent ran. The agent's plan for the change, including the alternatives considered and the rationale for the chosen approach. The agent's authoring of the change, including the patches the agent considered and the rationale for the final patch. The agent's confidence in the change, including any aspects of the change that the agent flagged as uncertain. The agent's testing of the change, including the tests written, the tests run, and the test outcomes.

The reasoning chain is not the prompt and it is not the model's raw output. It is a structured trace produced by the agent's tooling, with each step recorded as a typed event with structured payload. The trace is verbose because the auditor needs to be able to evaluate the reasoning, and brief reasoning is harder to evaluate than detailed reasoning. The trace is structured because the auditor's tooling needs to query against it efficiently. The trace is typed because the auditor needs to understand which steps are reads, which are writes, which are tests, and which are decisions.

The reasoning chain is replayable. The same reasoning chain, reapplied against the same codebase state, should produce the same change. This property is what allows the auditor to verify that the agent's reasoning was sound by replaying it with a different evaluator and checking the outputs. It also allows the company's own quality engineering to identify reasoning patterns that have produced problematic changes and to update the agent's prompt or the pact to address those patterns. Replayability is a substantial engineering investment but it is the property that makes the reasoning chain genuinely useful rather than just performatively complete.

The reasoning chain is required for security-relevant changes and is best-practice for all changes. A change to the authentication middleware requires the reasoning chain to include an explicit security-impact-analysis section that identifies the security properties the change might affect, the threat model the change was evaluated against, and the testing that was done to verify the security properties hold. The agent does not get to skip this section by deciding the change is not security-relevant. The pact specifies which paths are security-relevant and the agent's authorization gate enforces the analysis requirement.

The reasoning chain is the artifact that lets the auditor make a security impact assessment without needing to re-engineer the change. A FedRAMP assessor reviewing a change to a security-relevant file will read the agent's security-impact-analysis section, evaluate the threat-model coverage, and verify that the testing addressed the identified threats. If the reasoning chain is incomplete, the assessor will flag the change for additional engineering review, which is expensive. If the reasoning chain is complete and well-structured, the assessor can complete the assessment efficiently and the company's engagement with the assessor is substantially smoother.

H2 5: The reviewer's role and the structured review artifact

The human reviewer's role in the agent's change pipeline is more important than it would be for a human-authored change, not less. The reviewer is not just verifying that the change is correct, the reviewer is also verifying that the agent acted within its pact, that the reasoning chain is sound, and that the change does not introduce risks that the agent's reasoning failed to address. The reviewer's approval is the human authorization that the regime requires, and the structure of the review has to support the regime's expectations.

The review artifact is structured. It is not a free-form comment in the pull request. It is a defined set of review fields that the reviewer fills in to record their evaluation. The fields include the reviewer's identity and authority for the change category, the reviewer's evaluation of the agent's reasoning, the reviewer's evaluation of the change itself, the reviewer's evaluation of the tests, any concerns the reviewer raised and how they were addressed, and the reviewer's final approval. The fields are required, the review system rejects approvals that have not filled in the required fields, and the artifact is part of the per-commit provenance record.

The reviewer is qualified. The pact specifies the reviewer requirements per change category, and the review system enforces them. A change that requires security authority cannot be approved by a reviewer without security authority. A change that requires API-design authority cannot be approved by a reviewer who does not have it. The reviewer's authority is a property of the company's identity system, not a self-claim, and the trust layer's pact enforces the requirements at the merge gate.

The reviewer reads the reasoning chain. This is the most important behavioral change the reviewer has to make compared to reviewing a human-authored change. For a human-authored change the reviewer typically reviews the diff and asks the human about anything unclear. For an agent-authored change the reviewer has to read the reasoning chain and verify that the agent's investigation was sufficient, that the alternatives considered were the right alternatives, and that the rationale for the chosen approach was sound. The reviewer is reviewing the agent's reasoning as much as the agent's output, because the reasoning is what the auditor will eventually evaluate.

The reviewer can request changes that go beyond the diff. A reviewer might approve the change itself but request that the reasoning chain be amended to include an additional consideration the agent missed. A reviewer might request that the security-impact-analysis section be extended. A reviewer might request that additional tests be written before approval. The agent responds to the requests in the same way it responds to feedback on the diff, by amending the reasoning chain, the tests, or the change as needed. The iteration is recorded in the review artifact and is part of the provenance record.

The reviewer is not infallible and the regime does not assume the reviewer is. The auditor will sample reviewer approvals as well as agent commits, and a reviewer who is consistently approving changes that have substandard provenance records will be flagged. The company's quality engineering function has a responsibility to monitor reviewer behavior and to address patterns of inadequate review. The trust layer's audit trail makes the patterns visible because the reviewer's approvals are part of the structured record.

H2 6: The CI integration and the merge gate

The agent's CI integration is the technical surface where the provenance pipeline meets the existing change-management infrastructure. The integration has to work with whatever CI system the company has, and it has to enforce the provenance requirements without becoming the company's bottleneck. The merge gate is the control point that prevents commits without complete provenance from entering the protected branches.

The CI runs the provenance check as part of the standard pull request validation. The check verifies that the per-commit provenance record exists, that the required fields are populated, that the agent's certification tier is current, that the pact is current and authorizes the change category, that the reasoning chain is well-formed, that the security-impact-analysis section is present for security-relevant paths, and that the audit-trail anchor will be reachable. The check is fast, it does not run tests or compile code, it just verifies the structural completeness of the provenance record. A pull request that fails the check cannot proceed to the review stage.

The CI also validates the test coverage, the linting, the type checking, the security scanning, and any other automated checks the company runs on every pull request. These are the standard CI checks that operate on every change, and they apply to agent-authored changes the same as to human-authored changes. The agent has to pass them in the same way a human author would, by addressing any failures and updating the change. The CI's existing checks are not weakened for agent authorship, they are strengthened by the addition of the provenance check.

The merge gate is the control point at the end of the CI pipeline that admits commits to the protected branches. The merge gate enforces a specific set of conditions, the provenance record is complete, the CI checks have passed, the required reviewers have approved, the agent's certification is current, the pact authorizes the change. A commit that does not satisfy all of the conditions is not merged. The merge gate's enforcement is automatic and is not bypassable by individual engineers, even those with administrative authority on the version control system. The protected-branch configuration prevents the bypass.

The merge gate's behavior is logged. Every gate decision is recorded with the conditions that were evaluated and the result. The log is part of the audit trail. An auditor reviewing the merge gate's behavior can see that the gate has been operating consistently over the period, that no commits have bypassed it, and that the gate's conditions have been the conditions specified in the pact. The log is a critical piece of the audit trail because the auditor's questions about change-management controls include questions about the controls' operating effectiveness over the period.

The CI integration includes a mechanism for handling agent failures. An agent might produce a change that fails the provenance check because of a tooling issue, the reasoning chain might not have been recorded correctly, or the security-impact-analysis section might be malformed. The mechanism for handling these is to surface the failure to the engineering team, allow the team to investigate, and either fix the underlying tooling issue or escalate the change to human authorship under the standard human change process. The mechanism does not allow the team to manually attest to the missing provenance, because that would be a forgery of the audit trail. The change either has the provenance or it goes through the human pipeline.

H2 7: The model and prompt provenance

A part of the provenance record that often surprises engineering teams is the requirement to record the model and prompt that produced each commit. The auditor will ask not just who the agent was but what model the agent used and what prompt structure shaped the agent's behavior. The reason is that the agent's behavior is a function of its model and prompt, and a change in either can change the agent's risk profile. The provenance record has to capture this.

The model record includes the model's identifier, the model's version, the model's provider, and the model's compliance posture. The compliance posture is whether the model has been certified for the regulatory regime, whether the model is operated under the company's data-handling agreements, and whether the model's outputs are subject to any external retention or training. For FedRAMP Moderate the model has to be operated either by the company itself or by a FedRAMP-authorized provider, and the audit trail has to demonstrate that the model used for any given commit was the authorized model. A commit produced by an unauthorized model is a finding regardless of the quality of the change.

The prompt record includes the prompt template's identifier and version, the runtime parameters, and any retrieval-augmented context that informed the prompt at the time of the commit. The prompt template is itself a versioned artifact under the company's change management, with its own pact, review, and audit trail. A change to the prompt template is itself a change to the agent's behavior and is treated with the same rigor as a change to production code. The prompt record's reference to the template version is what allows the auditor to verify that the agent was operating under the prompt that was in effect at the time of the commit.

The model and prompt records together with the agent's reasoning chain are sufficient to reproduce the agent's behavior. An auditor or a quality engineer can take the same model, the same prompt, the same retrieval context, and the same input, and verify that the agent produces a similar output. Exact reproduction is not always possible because the model might have stochastic behavior, but the output should be functionally equivalent. The reproducibility property is what makes the provenance record genuinely auditable rather than just performatively complete.

The model and prompt are also the surfaces where the agent's behavior is most likely to drift over time. A new model version with different behavior can shift the agent's outputs in ways that the existing provenance pipeline does not detect because the pipeline is checking structural completeness rather than behavioral consistency. The company's quality engineering has to monitor for the drift, with regression tests against the agent's behavior on a stable benchmark, and the company has to update the pact and the prompt template as the model evolves. The pact's renewal cycle is the natural cadence for this work.

The model and prompt provenance also matters for inter-vendor portability. If the company decides to switch agent vendors, the new vendor's agent might use a different model and a different prompt template. The provenance pipeline can accommodate the change, but the audit trail will show the change and the auditor will want to see the security impact analysis for the change and the documented authorization for the new model under the pact. This is a feature, the audit trail makes the change visible, and the assessment of the change's risk happens explicitly rather than implicitly.

H2 8: The bond, the certification tier, and the trust oracle

The trust layer's role in the regulated code-generation pipeline is to provide the agent's identity, the agent's authority, the agent's reputation, and the bond that backs the agent's commitment. The trust oracle exposes these as queryable structured data, and the auditor's verification of the agent's compliance posture is grounded in the trust oracle's records.

The agent's identity is the unique identifier under which the agent is registered in the trust layer. The identity is stable over time, it is signed, and it is the principal that all of the agent's commits reference. The identity is what allows the auditor to look up the agent's history, the agent's certification tier, the agent's bond status, and the agent's pact roster. The identity is also what allows the company to detect any commit that claims to be from the agent but does not actually originate from the trust-layer-registered agent, because the commit's signature has to verify against the agent's registered key.

The agent's certification tier is the trust layer's summary of the agent's reliability, security, and operational posture. For regulated code-generation work, the pact typically requires a certification tier above a defined floor, with the floor calibrated to the regulatory regime. A FedRAMP Moderate codebase might require the agent to be at the top tier, with the demonstrated track record and the operational discipline that the tier represents. A SOC 2 codebase might allow a lower tier with appropriate compensating controls. The tier requirement is part of the pact and the merge gate enforces it.

The agent's bond is the economic stake the agent's vendor has posted against the agent's compliance with its pacts. For regulated code-generation work the bond is sized against the potential cost of a compliance failure, which can be substantial. A finding in a SOC 2 audit can cost the company a material customer contract. A finding in a FedRAMP assessment can delay or block federal contracts. The bond is calibrated against this exposure, and the slashing rules are calibrated to the kind of failure. A failure that produces an audit finding triggers slashing of a defined fraction of the bond, with the fraction depending on the finding's severity.

The trust oracle's record of the agent's compliance posture is queryable by the auditor. An assessor preparing for an engagement can query the trust oracle for the agent's certification tier, the agent's bond status, the agent's recent slashing events, the agent's recent dispute outcomes, and the comparable performance of similar agents. The query is part of the assessor's preparation and the answers shape the depth of the assessor's sampling. An agent with a strong trust oracle profile receives a less invasive assessment. An agent with a weak profile receives a more invasive one.

The trust oracle's records are also the basis for cross-buyer reputation. An agent that has performed well under one company's pacts has a record that another company can read when evaluating whether to deploy the agent in its own regulated environment. The cross-buyer reputation is what gives the trust layer its market function, agents with strong records can negotiate better terms, agents with weak records cannot. The market dynamic is what produces the agent vendor's incentive to invest in the provenance pipeline, the security discipline, and the operational quality that the regulated environment requires.

Reader artifact: The Code Provenance Audit Trail Spec

The specification below is the reusable artifact for this post. It is the structure we use to generate code-generation pact instances and the structure we recommend any company in a regulated environment adopt when deploying code-generation agents. The spec is opinionated about structure, with the specific values negotiable per pact.

Pact requirements. Agent identity registered in trust layer. Certification tier floor specified, must be current at every commit. Repositories and paths within repositories enumerated, with positive scope and explicit exclusions. Change categories defined with reviewer requirements per category. Maximum scope per single change. Testing requirements per change category. Security-impact-analysis requirements for security-relevant paths. Pact signed by authorized officer, hashed, anchored on Base L2. Pact renewed quarterly or semi-annually with operating-record review.

Per-commit provenance record. Required fields: principal identifier with agent ID, certification tier, run ID. Authority reference with pact ID and version. Inputs with ticket reference, prior-commit context, documentation references, conversation transcript, full reasoning chain. Test record with tests run, coverage delta, failures addressed. Review record with reviewer identities, authorities, structured reviews, iterations, final approval. Deployment record added at deployment time. Post-implementation documentation including release notes and any subsequent issue references. Audit-trail anchor linking record to chain.

Reasoning chain structure. Verbose, structured, typed, replayable. Captures interpretation of the ticket, investigation of the codebase, plan for the change with alternatives considered, authoring of the change with rationale, confidence assessment with uncertainty flags, testing of the change. Security-impact-analysis section required for security-relevant paths, with threat model coverage and testing rationale.

Reviewer requirements. Reviewer authority per change category, enforced by review system. Structured review artifact with reviewer identity, evaluation of reasoning chain, evaluation of change, evaluation of tests, concerns and resolutions, final approval. Reviewer reads reasoning chain, not just diff. Iteration records part of provenance.

CI integration and merge gate. Provenance check as standard CI step verifies structural completeness. Standard CI checks unchanged. Merge gate enforces provenance complete, CI passing, reviewers approved, certification current, pact authorizes change. Gate decisions logged. No bypass for individual engineers.

Model and prompt provenance. Model identifier, version, provider, compliance posture recorded per commit. Prompt template identifier and version, runtime parameters, retrieval context recorded. Models used must be authorized for the regulatory regime. Prompt templates versioned and pact-governed.

Trust oracle integration. Agent identity stable and signed. Certification tier queryable. Bond status queryable. Slashing events public. Dispute outcomes recorded. Cross-buyer reputation aggregated.

Bond and slashing. Bond sized against compliance failure exposure. Slashing rules calibrated to finding severity. USDC on Base L2. First-tier and second-tier dispute review.

Counter-argument: The pipeline is so heavyweight it negates the agent's productivity gains

The strongest counter-argument to the structured provenance pipeline is that its overhead is so heavy that it negates the productivity gains that justified deploying the agent in the first place. The pipeline requires structured reasoning chains for every commit, structured review artifacts, reviewer training in agent-authorship review, model and prompt provenance, audit-trail anchoring, and ongoing pact renewal. The argument is that the pipeline's engineering and operational cost exceeds the agent's contribution and the company would be better off using human engineers without the pipeline.

The argument has surface validity and it is wrong on the math. The pipeline's overhead is real, the reasoning chain capture adds latency to each agent action, the structured review takes longer than a free-form review, the model and prompt versioning requires its own engineering. But the alternative is not human engineers without the pipeline. The alternative is the case study above, where the agent is deployed without the pipeline, the audit eventually arrives, and the company absorbs the contract delay and the remediation cost. The right comparison is the pipeline's overhead against the cost of the audit failure, and the pipeline wins by an order of magnitude in any environment where the regulatory regime is taken seriously.

The pipeline's overhead also amortizes well at scale. The reasoning chain capture is a one-time engineering investment in the agent's tooling. The structured review artifact is a one-time configuration in the review system. The model and prompt versioning is a one-time discipline in the prompt-management system. The audit-trail anchoring is a one-time integration with the trust layer. Once the pipeline is built, the per-commit overhead is small, and the per-commit overhead is constant regardless of the agent's throughput. An agent processing ten thousand commits per month under the pipeline is producing ten thousand structured provenance records, which the auditor can sample efficiently and the company can query for any operational insight.

The argument that human engineers do not require the pipeline is also misleading. Human engineers do produce provenance, in the form of their commit messages, their pull request descriptions, their review comments, and their reputations within the company. The human provenance is unstructured and is reconstructed by the auditor at sampling time, which is expensive when the auditor is preparing for a high-stakes assessment. The agent's structured provenance is more efficient to audit than the human's unstructured provenance, and a company that runs both pipelines for both authorship patterns will eventually find that the agent's pipeline is a better template for the human pipeline rather than the other way around.

The argument that the pipeline kills the agent's flexibility is also worth addressing. A human engineer can make a quick change without writing a structured reasoning chain or a security impact analysis, and the company benefits from the agility. The agent under the pipeline cannot. This is correct, and it is the deliberate trade-off the pipeline makes. In a regulated environment the company has already accepted that agility is bounded by the regime's controls, and the agent's pipeline is enforcing those controls more rigorously than the human's process did. The agility loss is not new, it is the agility loss the regime always required, made visible by the agent's structured pattern.

What Armalo does

Armalo is the trust layer for the agent economy. For code-generation agents in regulated environments, the trust oracle exposes the agent's identity, certification tier, bond status, slashing history, and dispute outcomes as queryable structured data. Pacts are written against templates that include the seven properties the auditor expects, the per-commit provenance record schema, the reasoning chain requirements, the reviewer requirements, the CI integration, the model and prompt provenance, and the bond schedule. Pacts are signed on Base L2 with bonds held in USDC. The multi-LLM jury runs adversarial evaluations of the agent's behavior with a 20 percent trim on outliers, and the audit trail is Merkle-anchored hourly to the trust-layer audit anchor. The certification tier system gates eligibility for higher-regime pacts on demonstrated performance under prior pacts. The audit trail is permanent, queryable, and what gives companies the evidence they need when the SOC 2 auditor or the FedRAMP assessor arrives.

FAQ

Does the pipeline work with monorepos. Yes. The pact specifies the paths the agent can touch within the monorepo, with the same precision as for a single repository. Different parts of the monorepo can have different change-category requirements.

What happens if the agent's vendor is not FedRAMP-authorized. The agent cannot operate against a FedRAMP-scoped pact. The pact's certification floor will exclude unauthorized vendors. The vendor would need to obtain authorization or operate only against non-FedRAMP scopes.

How does the pipeline handle emergency changes. Emergency changes go through a separate emergency pact that bypasses the standard review timeline but does not bypass the provenance record. The emergency pact requires post-incident review with the same provenance fields populated.

Can the auditor query the trust oracle directly. Yes. The trust oracle exposes a public read endpoint for agent identity, certification tier, and aggregate metrics. Detailed records require appropriate access controls.

How do you handle the reasoning chain for a small change. The reasoning chain is proportional to the change. A small change has a brief reasoning chain. A security-relevant change has the security-impact-analysis section regardless of size.

What about commits to documentation. Documentation changes have their own change category in the pact, typically with simpler reviewer requirements. The provenance record is still required but the structure is lighter.

Bottom line

A code-generation agent in a regulated environment is a change agent that the regime did not anticipate. The pipeline that produces auditable provenance for every commit is the structure that makes the agent compatible with the regime. The pact is the agent's documented authority. The per-commit provenance record is the audit-ready artifact. The reasoning chain is the security-impact-analysis surface. The structured review is the human authorization. The merge gate is the control point. The bond is the economic stake. Skip any of these and the FedRAMP assessment turns into the nine-week contract delay.