Governing the Agentic SDLC Through Continuous Policy Enforcement

What it is

Agentic Process Evidence is a JFrog-proposed open protocol (spec at github.com/jfrog/agentic-process-evidence) for attaching signed records of AI agent work to the commit, artifact or release it produced. JFrog AppTrust ships it as "Prompt to Release Traceability". The page says no widely adopted standard for agentic provenance exists yet, so this is a vendor proposal seeking co-authors, not an established standard.

How it works

1. A runtime hook in the harness (Cursor, OpenCode, Claude Code or a custom worker) captures prompts, thinking tokens, file edits and tool calls as structured JSON session logs, then uploads them to persistent storage.
2. An in-toto Statement v1, signed with DSSE, is attached to the SDLC entity. Its subject is a gitCommit digest. Its predicate holds: - providers (harness, agent and model, with both inferenceProvider and a resolved dated model ID) - sessionsLogs (URI plus sha256) - tools - contextArtifacts (policy and guideline docs, hashed) - custom.requirements (e.g. a Jira ticket) - result, intents, owner, reviewers and timestamps
3. Promotion gates evaluate the evidence as policy-as-code. The page lists these checks: approved LLM, approved MCP tools, an accountable human owner, human review, no unapproved lateral operations, and alignment with the task and company policy.
4. Afterwards the evidence is searchable. If a tool is later found malicious, you search session logs for it and trace to the affected commits and releases, much as SBOMs allow for components.

The example Cursor session log uses hook events beforeSubmitPrompt, preToolUse, postToolUse, afterAgentResponse and sessionEnd, with path_hashes recorded before and after writes.

Preconditions / Affected

• You need a harness that can emit hook events, plus a signing and storage backend and a policy engine. The page names AppTrust as the implementation and does not describe a standalone one.
• Regulatory relevance is narrower than the marketing suggests. The page itself says EU AI Act Articles 12, 14 and 19 bind providers and deployers of high-risk AI systems. Article 14 covers oversight during use, not after-the-fact logging. The CRA and ISO/IEC 42001 are only described as "consistent with" this practice. Only the AISVS items (12.1.1 and 12.4.2) are quoted as voluntary requirements it maps to.

What to do

No commands are given. For an evaluator, the actionable parts are:

• Read the spec repo and compare its fields with what your harness hooks already emit.
• Decide whether your approved-model and approved-MCP lists could be expressed as gate policy.
• Pilot the commit-level evidence flow before depending on a vendor platform.

Caveats

• The page does not specify signing key identity, trust roots or how "approved" lists are defined. Whether evidence can be forged by a compromised workstation is not addressed.
• The example sets owner and reviewers to the same person (me@octocat.com), so a "human reviewed" gate would pass on self-review unless policy requires otherwise.
• The examples are mocks. predicateType is a placeholder, and the session log JSON is malformed, with a duplicated and truncated event.
• Logs capture prompts, thinking tokens, file contents and absolute paths. The only guidance is "we recommend not using personal data". Retention, redaction and access control are not covered.
• Checks like "aligned on the requested task" are listed without any mechanism for how they would be verified.