Governing the Agentic SDLC Through Continuous Policy Enforcement

What it claims

JFrog proposes the Agentic Process Evidence Protocol as an open, vendor-neutral evidence layer. Any harness (Cursor, OpenCode, Claude Code or custom workers are named as integration targets) would emit a signed attestation per agentic process, and SDLC gates would consume it. The spec lives at https://github.com/jfrog/agentic-process-evidence. The post presents it as a call for contributors, not a finished standard. No version, maturity level or existing third-party implementation is stated. The only shipping implementation named is JFrog AppTrust's "Prompt to Release Traceability".

How it works

The design depends on separating a session (one agent run or conversation) from a process (a goal achieved with one or more agents, such as agentic development or agentic PR review). Evidence is issued per process, and it references the session logs rather than embedding them.

1. Capture. A runtime hook records prompts, thinking tokens, file edits and tool calls. For interactive dev work this happens live. For processes like PR review it happens when the process completes. Logs are uploaded to persistent storage.
2. Attest. An in-toto Statement v1 is signed with DSSE. Its subject is the commit, artifact or release.
3. Gate. Policy-as-code evaluates the evidence alongside the usual scans, build provenance, approvals and tests.
4. Audit. If a tool is later found to be malicious, you search for the sessions that used it, then follow them to the commits and releases built with it.

flowchart LR
  H[Harness hook] --> L[Session log in storage]
  L -->|uri + sha256| E[Signed evidence on commit]
  E --> G{Release gate}
  S[Scans, provenance, tests] --> G
  G -->|pass| R[Promote]
  G -->|fail| B[Block]
  R -.tool flagged later.-> L

Session log shape (mock). The header carries:

• sessionId and parentSessionId
• affectedEntities (e.g. gitCommit)
• provider.harness, provider.agent and languageModels, where each model records both inferenceProvider and a resolved dated model ID

The timeline uses hook events beforeSubmitPrompt, preToolUse, postToolUse, afterAgentResponse and sessionEnd. Write tools record path_hashes before and after the write, which ties file content to the session.

Evidence predicate fields (mock):

• providers
• traceId (a process ID or CI job URI)
• sessionsLogs[{uri, digest.sha256}]
• tools[{name, version}]
• contextArtifacts: tagged policy or guideline, each with a digest and optional inline data
• custom.baseCommit and custom.requirements (Jira issue)
• result, intents, processSummary, owner, reviewers, start and end timestamps

Limits

• Placeholder predicate type. The predicateType is https://my-organization.com/evidence/<agentic-code-review|agentic-dev-process>/v1. No canonical predicate URI is published in the post, so interoperability depends on what the repo defines.
• Unexplained policy checks. Gate checks such as "aligned on the requested task" or "followed corporate guidelines" are listed, but the post gives no mechanism for evaluating them. Only checks on concrete fields (approved model IDs, tool list, owner and reviewer present) are evident from the schema.
• reviewers is self-reported. In the example the owner and reviewer are the same person (me@octocat.com), and nothing shown verifies that a review happened.
• Broken sample JSON. The session-log sample has a duplicated, unterminated preToolUse event and an invalid UUID. Don't copy it as a fixture.
• Personal data. The logs capture prompts, paths and emails, and JFrog itself recommends keeping personal data out.
• Weak regulatory fit. By the post's own admission, EU AI Act Articles 12, 14 and 19 bind providers and deployers of high-risk AI systems, and Article 14 concerns oversight while a system is in use, not after-the-fact logging. The regulatory mapping is directional, not a compliance requirement for coding agents.
• No evidence. The post reports no deployments, performance overhead or storage costs.