PaperlayerView exact revision on arXiv

Source-linked AI summary

Agentic process evidence

Yuval Kainan, Carmit Hershman

arXiv:2610.40071v1cs.AIcs.SEcs.SYeess.SY

TL;DR

AI agents increasingly produce code, while commits do not identify the agent systems behind changes. Agentic Process Evidence records sessions and binds them to a process outcome. The paper presents a governance system designed for gating and retrospective auditing.

  • Problem

    Agent systems can affect changes without being named in the commit, leaving no process record to identify the sessions behind the outcome.

    Source: §1.3 · p. 2

  • Method

    Agentic Process Evidence creates a signed, tamper-evident statement linking the sessions that affected a process to its outcome and recording agent and session claims.

    Source: §3 · p. 5

  • Results

    The paper presents a general agentic-process governance system designed to support both gating and retroactive auditing.

    Source: §5 · p. 13

  • Takeaways & Limitations

    The evidence lets operators test declared policy against sessions tied to an outcome before that outcome crosses a gate.

    Source: §5 · p. 14

    The predicate does not detect compromise; it makes collected events retrievable from the outcome.

    Source: §5 · p. 14

Abstract

from arXiv · show

The way software gets built is changing dramatically. AI agents now create pull requests, select dependencies, refactor codebases, interpret test failures, and execute infrastructure changes across the entire Software Development Life Cycle (SDLC). AI agents are autonomous team members, but unlike human engineers, they are ephemeral - their reasoning, decisions, and tool calls vanish the moment the session ends. Modern Security incidents involving intent mismatch or injection are becoming increasingly common - forcing us to address AI Agents as an insider threat. No widely adopted standard yet enables agentic provenance and governance and its obvious that you can't hold an ephemeral process accountable. The git log was designed for human commits. It shows what changed. It does not show what an AI agent did, which model it used, which tools it called, or whether anyone was accountable for the outcome. Every governance framework, every audit trail, every compliance control in the SDLC was built around one assumption: a human made the decision. That assumption no longer holds. This shift introduces 3 main procedural problems (not addressing scale) - Supply-chain vector - The agentic coder is software, so it is a supply-chain security risk. Policy guardrails - How to ensure the agentic coder is compliant with the policies of the organization. Task-alignment - How to align the agentic coder on its tasks and goals. We introduce Agentic Process Evidence (APE), a signed, tamper-evident, machine-readable attestation of agentic processes, linking the sessions to their outcome (process-aware logging). APE enables Policy-as-Code control over the agentic processes, allowing for human in the loop only when it's needed. We support the in-toto style attestation framework, and the protocol is aligned with the relevant regulations

1 Introduction

AI agents increasingly produce software changes, but existing controls and records assume an accountable human remains connected to each change. The introduction frames the missing link as process evidence tying agent sessions to outcomes so organizations can govern and audit them.

1.1 AI now writes the code

  • Google reported 75% of new code generated by AI and engineer-approved, versus 50% the previous fall; Microsoft reported 20% to 30% in some repositories (Pichai, 2026; TechCrunch, 2025).The paper cautions that these are different measurements, not an industry consensus.Source: §1.1 · p. 2

1.2 Controls built for human authors

  • Human-centered controls attach ownership, review, and audit to an available person, but an agent's session ends without a colleague to question.Commits, reviews, protected branches, and required checks were built around human authors.Source: §1.2 · p. 2

1.3 Supply-chain risk

  • An agent combines models, harnesses, tools, and servers, creating a supply-chain risk that artifact inventories cannot connect to the sessions behind a change.The process provenance should be tied to the agent's blast radius, while acceptance decisions belong on the delivery platform.Source: §1.3 · p. 2

1.4 Control over an ephemeral process

  • Because agents and sometimes their devices are ephemeral, trust must attach to the outcome, where operators can inspect affected sessions and whether declared rules were followed.Without that record, changes are either taken on faith or reviewed as if the session had never been recorded.Source: §1.4 · p. 2

1.4.1 Company policy

  • Runtime controls such as rules, hooks, and allow-lists operate inside the harness, but the commit does not show whether policy was active or checked.A session that bypasses a rule or whose refusal is not collected can still produce the commit.Source: §1.4.1 · p. 3

1.4.2 Task-alignment

  • Task-alignment means comparing recorded processes with the task and declared policy, then accepting, rejecting, or escalating outcomes before they advance in the SDLC.The paper says identifying potentially misaligned outcomes—not preventing the cited incident—is its goal.Source: §1.4.2 · p. 3

1.5 The missing record

  • Governance and provenance share a missing record: transcripts must link agent sessions to the commits they affected.Existing transcripts that do not name an outcome are only logs, and a diff cannot stand in for a session.Source: §1.5 · p. 3

2 Related Work

Existing supply-chain, composition, runtime, signing, and policy tools record different aspects of software production, but none links an agent session to the commit it affected. This section distinguishes those existing mechanisms from the missing process-to-outcome link.

2 Related Work

  • Build provenance, bills of materials, runtime receipts, signed evidence, and Policy as Code each answer a different question; none links an agent session to its affected commit.The signing and policy-evaluation tools already exist; the missing element is the link itself.Source: §2 · p. 3

2.1 Supply-chain attestation

  • in-toto provides signed link metadata for checking expected supply-chain steps, while the Attestation Framework standardizes statement structure and SLSA applies it to build provenance (Torres-Arias et al., 2019; OpenSSF, 2023).DSSE wraps the signed payload, and Sigstore binds short-lived keys to established identities and logs signatures.Source: §2.1 · p. 4

2.2 Composition records

  • SPDX and CycloneDX describe artifact contents, and an AI bill of materials can name a model, but neither records which session produced a change.They support identifying artifacts containing a vulnerable component, not the model, tools, or human review behind a change.Source: §2.2 · p. 4

2.3 Agent runtime evidence

  • TRACE v0.2 records runtime identity, policy, data class, and a tool-transcript hash but does not bind execution to its resulting commit or release.Anthropic's hooks and AWS Dogwood are lifecycle and tool-call enforcement points, not the predicate specified here.Source: §2.3 · p. 4

2.4 Evidence

  • A valid signature shows that a configured signer produced an immutable payload, but does not establish that all relevant facts were included or that its claims are true.The existing in-toto statement format does not say which agent sessions affected a commit.Source: §2.4 · p. 4

2.5 Policy as Code

  • Policy as Code evaluates structured input against declared rules, but the engine neither creates the fields being checked nor links a session to a commit.Whether code satisfies a requirement written in prose lies outside the deterministic field comparisons described here.Source: §2.5 · pp. 4–5

3 Agentic Process Evidence

Agentic Process Evidence links agent sessions to the business-process outcome they affect, enabling provenance, policy checks, task-alignment checks, and accountability. It defines session logs and process evidence, then describes components for capturing, storing, and governing that evidence.

3 Agentic Process Evidence

  • Governance queries cover supply-chain provenance, policy compliance, task alignment, mandatory context, and accountability, including ownership and human review.The system is designed for both gating and retrospective auditing.Source: §3 · p. 5

3.1 Agentic sessions

  • Each agentic session is one run or conversation, with a log artifact recording prompts, replies, and tool or MCP use, including arguments and results.A session log describes what happened in the session, but does not by itself describe its outcome.Source: §3.1 · p. 5

3.2 Agentic processes

  • An agentic process achieves a business goal through one or more sessions and has a stable identifier and one outcome, such as a commit or support ticket.The outcome identifier may not exist when the first session begins.Source: §3.2 · p. 7

3.3 Agentic process evidence

  • APE identifies sessions affecting a process and records agent, model, tools, context, owner, reviewer, result, and time claims in signed, tamper-evident evidence.For code development, the process is identified by its commit; the evidence is produced once the process completes.Source: §3 · p. 5, §3.3 · p. 7
  • APE signs the process outcome and digest-linked session logs in an in-toto Statement v1 within a DSSE envelope; edited payloads fail verification, but deletion remains possible.The evidence includes agent identity, execution traceability, process provenance, and policy context; Table 3 lists its fields.Source: §3.3 · p. 7

3.4 System Implementation

  • The implementation describes session capture, evidence production, and policy-controlled human review, but does not report these components operating.Figure 2 depicts logs uploaded to a registry, signed process evidence, policy evaluation, and a gate verifying records before production.Source: §3.4 · p. 9, Figure 2 · p. 9

3. Gating system side

The implementation separates session capture, evidence storage, policy evaluation, and delivery gates. Gates verify signed process evidence and cited logs, while semantic policies evaluate session logs for checks that structured fields alone cannot address.

3.4.1 Agent runtime side

  • Runtime attachment can use harness hooks, an in-harness transcript, or a proxy, but each captures only calls that reach it.The collector, log store, and signing key must be trusted inputs outside the agent’s reach; a valid signature does not prove every session was reported or every event is true.Source: §3.4.1 · pp. 9–10

3.4.2 Registry side

  • The registry stores content-addressed session logs and signed evidence so later fetches can verify the original bytes, including when logs are deleted or amended.It returns evidence and logs as structured input; policy evaluation belongs to the Policy-as-Code engine, not the registry.Source: §3.4.2 · p. 10

3.4.3 Gating system side

  • At a chosen delivery gate, missing evidence, an invalid signature, or a mismatched log digest blocks progression; deterministic and semantic checks evaluate evidence and logs.The gate matches the evidence subject to the outcome obtained independently; its policy engine and bundle are part of the trusted computing base.Source: §3.4.3 · pp. 10–11

3.4.4 Semantic policy integration

  • Outcome governance checks the result but lacks session context, while process governance can assess task alignment and other questions using semantic policies over session logs.A classifier trained per policy is fast at inference but requires expertise, labeled data, and retraining; an LLM judge is flexible but expensive.Source: §3.4.4 · p. 11

4 Use-case implementations

The use cases apply the evidence envelope to code development, code review, and customer support, with the process identifier and evidence subject varying by outcome. Code-development evidence is associated with a commit; support evidence may omit logs when they contain a third-party product secret.

Autonomous and human-in-the-loop code development

  • Autonomous and human-in-the-loop code development both identify the process by commit SHA and use the code-development process type.The autonomous example has no live human review; the human-in-the-loop example keeps a developer involved through commit and review.Source: §4 · p. 12

Code review

  • Code review records an agent’s approval or rejection as a verdict on the commit, using the code-review process type.The example uses one review session and can involve no person when the change is negligible.Source: §4 · p. 12

Customer success

  • Customer success treats a support ticket as the process identifier and the session log or support case as the evidence subject.Session logs may be omitted when their content is a third-party product secret.Source: §4 · p. 12

Process definition for code creation

  • For code creation, the process is defined as a commit reaching the company’s central main or master branch, excluding local commits rewritten through amend, rebase, or cherry-pick.Evidence names the central-branch commit once it exists.Source: §4 · p. 12

5 Discussion

The discussion frames agentic governance around supply-chain, policy, task-alignment, and accountability risks, and presents a system for gating and retrospective audit. It also identifies capabilities for further development, including line-level evidence, long-lived processes, real-time gating, and semantic-policy computation.

5 Discussion

  • Agent use raises supply-chain security, policy-compliance, task-alignment, and accountability questions, while agents’ ephemeral decisions and rationale can be lost when sessions end.The system asks which harness, agent, model, tools, and context affected a process, whether policy and architecture guidelines were followed, and whether a human reviewed it.Source: §5 · p. 13
  • The paper presents a general governance system designed for both gating and retroactive auditing of agentic processes.Its governance questions include task relevance, new decisions, mandatory context, and human accountability.Source: §5 · p. 13
  • When a tool, harness, model, or MCP server is later found compromised, process evidence points to the sessions that used it so an audit can retrieve their logs.The predicate makes collected event records retrievable from the outcome; it does not detect the events.Source: §5 · pp. 13–14
  • Task-alignment makes a declared policy testable against sessions affecting an outcome before that outcome crosses a gate, but does not establish whether the policy itself is right.The system is designed to keep logging and evidence outside the agent’s reach as a source of truth.Source: §5 · pp. 13–14
  • The discussion identifies line-level evidence integration and support for long-lived processes as directions for further development.The long-lived-process direction concerns setting subprocesses and gates to align agents across those processes.Source: §5 · p. 14
  • Further directions include real-time gating against malicious or misaligned behavior and continued research on semantic-policy computation, which is relatively new and evolving.The discussion also points to integration with line-level attribution systems such as Agent Trace (Agent Trace, 2026).Source: §5 · p. 14

A Related regulations

The appendix distinguishes regulatory duties from an agent-session format and supplies predicate-field profiles and JSON examples. The supplied examples include human-in-the-loop code development.

A Related regulations

  • The appendix says the cited regulations and standards do not define an agent-session format, and adopting the protocol is not a compliance certificate or legal advice.Organizations must decide whether a workflow is high-risk and whether they act as provider or deployer.Source: A Related regulations · p. 16
  • The appendix summarizes regulatory scope, including that the cited AI Act provisions govern high-risk systems in operation and do not automatically govern development tools producing another product.The appendix also notes that logging and human oversight are distinct duties, and that the cited Cyber Resilience Act and ISO/IEC 42001 do not specify an agent-session log or signed process attestation.Source: A Related regulations · pp. 16–17

B Use-case predicate fields

  • The use-case profiles specify predicate fields that gates read, with fields marked mandatory for the relevant profile; examples are provided in Appendix C.The supplied captions identify profiles for human-in-the-loop development, autonomous development, code review, and customer success.Source: B Use-case predicate fields · p. 17, Table 5 · p. 17, Table 6 · p. 18

C.1 Human-in-the-loop code development

  • The human-in-the-loop code-development example provides three session logs for one commit, with the first log recording the prompt, reasoning, reply, and tool and MCP use.The other two logs are cited by digest in the statement rather than repeated in the example.Source: §C.1 · p. 21

C.1.1 Session log {

The session-log example records an agent run through its prompt, reasoning, replies, and tool interactions. Its event entries include both tool calls and their results.

C.1.1 Session log {

  • The example records the provider, agent, and language-model identifiers alongside the timeline of session events.It identifies Cursor 3.5.33, cursor-agent 1.0, and anthropic/claude-opus-4-8 with a resolved model version.Source: §C.1.1 · p. 21
  • The example begins with a prompt to implement token-bucket rate limiting on POST /api/orders and records the agent’s stated plan to consult development guidelines and inspect the service.It also records a read of the development-guidelines file before the implementation write.Source: §C.1.1 · pp. 21–22
  • The log records an MCP tool call to list routes for the orders service and its returned route, POST /api/orders.The finished call is represented by a postToolUse event with the same tool-use identifier as the call.Source: §C.1.1 · p. 22
  • A Write tool event records the rate_limit.py path and contents, followed by a postToolUse event containing a path hash for that file.The example’s path_hashes value is null on the pre-tool event and a hash string on the post-tool event.Source: §C.1.1 · pp. 22–23
  • The recorded agent reply says it added token-bucket rate limiting, and the timeline ends with a sessionEnd event.The commit identifier also appears in the example’s affected-entity information.Source: §C.1.1 · pp. 21, 23

C.1.2 Process evidence

The examples show process evidence linking session logs to code-development outcomes and alignment evidence recording policy results. They cover human-reviewed and autonomous development cases.

C.1.2 Process evidence

  • The human-in-the-loop process statement identifies a code-development process, its commit, three cited session logs, provider and model details, tools, context artifacts, requirements, result, and intent.Its process summary says three sessions produced the commit for pre-merge review.Source: §C.1.2 · pp. 23–25

C.1.3 Alignment evidence

  • The human-in-the-loop alignment statement records policy results for mandatory-context, development-guideline, and architecture-guideline checks against the same commit.Each listed policy result is ALIGNED.Source: §C.1.3 · pp. 25–26

C.2 Autonomous code development

  • The autonomous example uses the same object types, with process evidence naming an owner and no human reviewer and alignment evidence scoped to one session log.Its process summary describes one agent session producing a commit for pre-merge review.Source: §C.2 · p. 27, §C.2.2 · pp. 29–30

C.2.1 Session log

  • The autonomous session-log example records a Write event for rate_limit.py, its post-tool path hash, and the agent’s response describing the change.It also includes the original prompt and a read of the development-guidelines document.Source: §C.2.1 · pp. 27–28

C.2.2 Process evidence

  • The autonomous process statement identifies a code-development outcome and records its owner, provider and agent details, tool, context artifacts, requirements, result, and intent.Its process summary says one agent session produced the commit and that the statement names an owner but no human reviewer.Source: §C.2.2 · pp. 29–30

C.2.3 Alignment evidence

  • The autonomous alignment statement lists policy context artifacts and records alignment results for the development and architecture guidelines.The supplied fields also identify a session-alignment process and an alignment-checker agent.Source: §C.2.3 · pp. 30–31

C.3.1 Session log

The examples show session-level event logging and process evidence for code-review and customer-support workflows, alongside separate alignment evidence. The records capture actions, outcomes, and policy context.

C.3.1 Session log

  • The code-review session log captures the review prompt, Read and GitDiff calls, and the agent's risk classification and approval response.Source: §C.3.1 · p. 32

C.3.2 Process evidence

  • The code-review process statement summarizes a STANDARD rate-limiter change as approved but not auto-merge eligible, linking it to commit and session-log evidence.Source: §C.3.2 · pp. 33–34

C.3.3 Alignment evidence

  • The code-review alignment statement records the alignment-checker and the organization review-rubric policy artifact with its digest.Source: §C.3.3 · pp. 34–35

C.4.1 Session log

  • The support session log records a refund request, policy and order lookups, and the agent's denial based on the 14-day refund window.Source: §C.4.1 · p. 36

C.4.2 Process evidence

  • The support-process evidence marks ticket SUP-8821 completed and summarizes the denial of a refund for order 44119 under the 14-day policy.Source: §C.4.2 · p. 37

C.4.3 Alignment evidence

  • The support alignment statement records the alignment-checker, support-refund-policy artifact, and evidence creation timestamps.Source: §C.4.3 · pp. 38–39
Loading 2610.40071v1…