Blog Home

Governing the Agentic SDLC Through Continuous Policy Enforcement

Carmit Hershman
Yuval Kainan

By Carmit Hershman, JFrog Senior Software Architect, CTO Office Yuval Kainan, JFrog AI Architect, CTO Office

14 min read

The way software gets built has changed faster than the standards that govern it. 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. You can’t hold an ephemeral process accountable. No widely adopted standard yet captures agentic provenance.

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.

Why Does Agentic SDLC Break Traditional Governance?

SDLC trust was built around humans. Peer code review meant a human engineer signed off before merging. Traceable intent meant commits mapped to human identities and Jira tickets. Release gates meant a human verified quality before deployment. Compliance frameworks from SOC 2 to FedRAMP were formalized before the agentic era and therefore focused on humans.

The Agentic SDLC strains these anchors:

  1. Volume overload and rubber-stamping: Humans reviewing thousands of lines of agentic code per hour experience fatigue that can turn peer reviews into automatic approvals.
  2. Agent misalignment and hallucinations: Agents make non-deterministic decisions, pull dependencies, and introduce latent vulnerabilities that pass functional tests.
  3. Agents are ephemeral: Git commit logs only capture the final state, not the agent’s reasoning, the tools it invoked, the MCP (Model Context Protocol) servers it queried, or the prompt iterations that produced the result.

The Agentic SDLC also opens new supply chain attack surfaces. The new actors in your software supply chain (agents, harnesses, and LLMs that now produce software and handle releases) introduce new attack vectors: prompt injections, malicious MCP tools and skills, misaligned or non-approved models, and jailbreaks.   

Where Regulation and Standards Are Heading

The challenges are reshaping both regulation and security standards. The EU AI Act sets record-keeping and log-retention duties for high-risk AI systems, and the OWASP AI Security Verification Standard (AISVS) sets comparable voluntary verification requirements.

  • EU AI Act, Article 14 (high-risk AI systems): “High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.”
  • EU AI Act, Article 12 (high-risk AI systems): “High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.”
  • OWASP/AISVS 12.1.1: “Verify that AI interactions are logged with session context and AI-specific telemetry.”
  • OWASP/AISVS 12.4.2: “Verify that audit logs capture security-critical proactive actions, including approver identity, timestamp, action parameters, and decision outcomes.”

Articles 12, 14, and 19 bind providers and deployers of high-risk AI systems. Article 14 addresses oversight while a system is in use rather than after-the-fact logging. The direction of travel is still clear. In our view, this practice is consistent with the security-by-design expectations of the EU Cyber Resilience Act and the governance approach of ISO/IEC 42001.

Teams should attach this provenance directly to the SDLC entity the process produced: a commit, artifact, or released version. That attachment enables automatic release gating through policies, post-release troubleshooting, and other downstream safety checks.

Every agentic session should leave a signed, portable evidence trail: what the agent did, which models and tools it used, who owned the process, and whether a human reviewed it. That trail binds to the commit or release it produced, travels with the artifact through every promotion gate, and helps answer an auditor’s questions without manual reconstruction. It works regardless of which harness, IDE agent, or SDLC platform produced it. 

That is the standard JFrog is proposing. JFrog AppTrust’s recent capability, Prompt to Release Traceability, connects agent session logs to signed release evidence across the SDLC. We based our solution on Supply-chain Levels for Software Artifacts (SLSA), the OpenSSF-backed supply chain security framework, and rely on SLSA-compatible provenance attestations that connect agent activity to signed releases. The full spec lives in the reference repository on GitHub.

Building an Open Standard Together

The shift to an agentic SDLC requires a new foundation for trust, accountability, and traceability. Agentic Process Evidence is an open effort to establish that foundation together.

For regulatory bodies, agent providers, and SDLC tool providers

The goal is not another proprietary telemetry format. It is an open, verifiable evidence standard for the agentic SDLC, one that organizations, regulators, agent providers, and SDLC platforms can rely on.

Agentic software development is evolving faster than existing governance models. The industry needs an open, interoperable standard for capturing and verifying evidence of agentic processes and intents.

If you are a regulatory body, standards organization, AI agent provider, or LLM/harness developer, help us shape the standard. Contribute requirements, use cases, feedback, and implementations so that Agentic Process Evidence can become a common language across the ecosystem.

→ Explore the specifications and contribute on GitHub https://github.com/jfrog/agentic-process-evidence

Whether you build source control, CI/CD, security, code review, developer tooling, or another SDLC platform, let’s work together on the evidence layer that connects them all. Organizations should not have to choose between competing platforms to achieve trustworthy, portable agentic provenance.

We can compete at the product layer while collaborating on the standard.

→ Join the Agentic Process Evidence initiative https://github.com/jfrog/agentic-process-evidence

Under the Hood: Agentic Process Evidence Protocol

AI agents now participate in every stage of the SDLC: editing code, promoting artifacts, managing deployments, and running security checks. To govern these processes with the same rigor used for traditional releases, we need a deterministic, cryptographic mechanism that records and evaluates what agents do. We call this the Agentic Process Evidence Protocol.

The protocol separates two concepts that are easy to conflate:

  • Agentic session: a single agent run or conversation
  • Agentic process: a process achieving some goal using agents

Examples of processes and their related sessions:

Process Name Process Target Session Examples
Code development Commit IDE agent sessions, terminal coding agent sessions, cloud coding agent sessions.
Code review Commit Code review agent running autonomously in a CI server.
Customer support Support ticket A chatbot handling support tickets, interacting with a customer.

 

The Agentic Process Evidence Protocol defines a structured specification for capturing, attesting to, and verifying agentic processes executed throughout the software release lifecycle. Each process produces Agentic Process Evidence: a tamper-evident, signed attestation containing signed facts about what the agent did, which models and tools it used, who owned the process, whether a human reviewed it, and the session logs of every interaction that produced it.

By integrating the protocol into agent frameworks such as Cursor, OpenCode, Claude Code or custom AI workers, agent actions generate verifiable evidence alongside software development outputs. That evidence is then used throughout the SDLC gates and later for troubleshooting, allowing the engineering and security teams to answer questions such as:

  1. Did the agents violate policy?
  2. Is every agent using an approved LLM?
  3. Does every agentic dev session have an accountable owner?
  4. Did the agentic dev session use requirements from corporate Jira?
  5. Did the agentic dev session follow corporate dev guidelines?

How Does the Agentic Process Evidence Protocol Work?

The Agentic Process Evidence Protocol captures agent activity in four steps: the runtime hook records the session, a signed evidence statement binds it to the SDLC entity, policy gates evaluate it before promotion, and the logs persist for post-release auditing and troubleshooting.

Step 1: Agent Execution & Telemetry Capture

The runtime captures the agent’s operational context as it works: user prompts, thinking tokens, file edits, and tool calls. It then records these actions into session logs and binds them to the relevant SDLC entity, such as the git commit the agent produced.

For other agentic processes, such as agentic PR review, the system captures this once the agent completes its process. The runtime hook uploads the session logs to persistent storage for later retrieval.

Step 2: Cryptographic Attestation & Evidence Push

The protocol crafts, signs, and stores provenance evidence as a metadata layer attached directly to the relevant SDLC entity (a git commit, an artifact, a released version) that the agentic process handles and binds to the logs, signing their status as well.

Step 3: Automated Quality, Compliance and Alignment Gates

Before software moves into staging or production, deployment gates evaluate binary security scans, build provenance, manual approvals, automatic testing, plus the attached Agentic Process Evidence. Policy-as-code can now verify that:

  • The agent work was aligned on the requested task
  • The agent is aligned on the company policies
  • There is a human accountable for the operation
  • Code was developed with human review
  • The agent did not attempt unapproved lateral operations
  • The code was generated by an approved LLM
  • The agent used approved MCP tools

Approving software based on evidence and policy-as-code supports demonstrating compliance without last-minute audit scramble or heavy post-release checks.

That is continuous compliance in practice: governance that ships with every release, without slowing developers down, and stays visible to auditors.

Step 4: Auditing & troubleshooting

Binding agentic process evidence and session logs into the standard SDLC entities (git commits, artifacts, released versions) enables post-release auditing and troubleshooting of issues identified with agentic tools, models or agents, the same way Software Bills of Materials (SBOMs) made artifact composition traceable.

For example, if a tool is at some point identified as malicious, we can search for the session logs that used it and, through these logs, identify commits and software releases that were created using that tool. The three-part model ties these steps together: session logs capture what happened, process evidence binds those logs to the SDLC entity they produced, and each implementation specializes that evidence for its specific process.

High Level Model Diagram

What Does Agentic Process Evidence Actually Capture?

The Agentic Process Evidence Protocol captures five categories of facts per agentic process: agent identity, execution traceability, provenance, integrity, and policy compliance. Each field is cryptographically signed and attached to the SDLC entity the process produced, making every agentic session auditable after the fact.

  • Agent identity: The protocol cryptographically binds each agent’s parameters to its output, capturing the agent version, harness version, and model ID for language model governance.
  • Execution traceability: The protocol records the full session logs as structured JSON, covering every tool call, API call, input, and context source in the timeline.
  • Provenance: The protocol binds the SDLC entity (a commit, artifact, or release) back to the agentic process and its logs.
  • Integrity and tamper-evidence: In-toto and Dead Simple Signing Envelope (DSSE) sign the execution payload, making any modification after the fact immediately detectable.
  • Policy-as-code verification: Governance engines evaluate compliance rules automatically and can block a release before it deploys.

Artifacts example

Here’s what that looks like end-to-end, from the agent’s first action to the signed evidence attached to the commit. Let’s assume a developer wants to implement ticket FIN-3678 that defines a new rate limit feature on an existing api /api/orders. A user called ‘me’ requests the agent in an IDE to implement the feature and follows the development progress. Once satisfied, the user commits the feature (or asks the agent to commit it), producing the agentic session log and the process evidence. For simplicity, let’s assume the development only required a single agentic session and was followed by a single git commit.

Agentic session log

The following is a mock example of a session log produced while the IDE agent developed a feature of rate limiting on api called /api/orders.

Please note: we recommend not using personal data in this.

{
  "sessionId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "parentSessionId": "4o7g54cd-8957-7503-45ga-495867457986",
  "affectedEntities": [{"gitCommit": "bf02510c8ce0b804a099797510af"}],
  "provider": {
    "harness": {
      "name": "cursor",
      "version": "3.5.33"
    },
    "agent": {
      "id": "stable-agent-id",
      "name": "cursor-agent",
      "version": "1.0"
    },
    "languageModels": [
      {
        "inferenceProvider": "anthropic/claude-opus-4-8",
        "resolved": "anthropic/claude-opus-4-8-20260701"
      }
    ]
  },
  "timeline": [
    {
      "eventId": "evt_01HZX9K2M3N4P5Q6R7S8T9",
      "event": "beforeSubmitPrompt",
      "ts": "2026-04-08T08:51:02.114Z",
      "hook_event_name": "beforeSubmitPrompt",
      "prompt": "Implement rate limiting on /api/orders, use jira FIN-3678",
      "conversation_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "cwd": "/Users/dev/gh-org/gh-repo",
      "workspace_roots": ["/Users/dev/gh-org/gh-repo"]
    },
{
      "eventId": "evt_01HZX9K2M3N4P5Q6R7S8T0",
      "event": "preToolUse",
      "ts": "2026-04-08T08:51:18.441Z",
      "hook_event_name": "preToolUse",
      "tool_name": "Write",
      "tool_use_id": "toolu_01ABC...",
      "tool_input": {
        "path": "/Users/dev/gh-org/gh-repo/src/orders/rate_limit.py",
        "contents": "..."
      },	
    {
      "eventId": "evt_01HZX9K2M3N4P5Q6R7S8T0",
      "event": "preToolUse",
      "ts": "2026-04-08T08:51:18.441Z",
      "hook_event_name": "preToolUse",
      "tool_name": "Write",
      "tool_use_id": "toolu_01ABC...",
      "tool_input": {
        "path": "/Users/dev/gh-org/gh-repo/src/orders/rate_limit.py",
        "contents": "..."
      },
      "path_hashes": {
        "/Users/dev/gh-org/gh-repo/src/orders/rate_limit.py": null
      },
      "conversation_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
    },
    {
      "eventId": "evt_01HZX9K2M3N4P5Q6R7S8T1",
      "event": "postToolUse",
      "ts": "2026-04-08T08:51:19.102Z",
      "hook_event_name": "postToolUse",
      "tool_name": "Write",
      "tool_use_id": "toolu_01ABC...",
      "path_hashes": {
        "/Users/dev/gh-org/gh-repo/src/orders/rate_limit.py": "e3b0c44298fc1c149afbf4c8996fb924..."
      },
      "conversation_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
    },
    {
      "eventId": "evt_01HZX9K2M3N4P5Q6R7S8T2",
      "event": "afterAgentResponse",
      "ts": "2026-04-08T08:52:01.880Z",
      "hook_event_name": "afterAgentResponse",
      "text": "Added token-bucket rate limiting on /api/orders.",
      "conversation_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
    },
    {
      "eventId": "evt_01HZX9K2M3N4P5Q6R7S8T3",
      "event": "sessionEnd",
      "ts": "2026-04-08T08:52:05.010Z"
    }
  ]
}

 

Agentic process evidence: example output

Below is a mock evidence example of the agentic process defined above, committing that code into git.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "uri": "https://github.com/my-organization/hello-world/commit/bf02510c8ce0b804a099797510af...c19325acfb979538c5b521304c83cde63892",
      "digest": {
        "gitCommit": "bf02510c8ce0b804a099797510af...c19325acfb979538c5b521304c83cde63892"
      }
    }
  ],
  "predicateType": "https://my-organization.com/evidence/<agentic-code-review|agentic-dev-process>/v1",
  "predicate": {
    "providers": [
      {
        "harness": {
          "name": "cursor",
          "version": "3.5.33"
        },
        "agent": {
          "id": "stable-agent-id",
          "name": "cursor-agent",
          "version": "1.0"
        },
        "languageModels": [
          {
            "inferenceProvider": "anthropic/claude-opus-4-8",
            "resolved": "anthropic/claude-opus-4-8-20260701"
          }
        ]
      }
    ],
    "traceId": "process id | ci_job_run_uri",
    "sessionsLogs": [
      {
        "uri": "session log url",
        "digest": {
          "sha256": "session log sha..."
        }
      }
    ],
    "tools": [{"name": "tool-name", "version": "tool version"}],
    "contextArtifacts": [
      {
        "tags": ["policy"],
        "uri": "link-to-development-guideline",
        "data": "The complete artifact document inline",
        "digest": {
          "sha256": "policy-sha256"
        }
      },
      {
        "tags": ["guideline"],
        "uri": "link-to-architecture-guidelines",
        "digest": {
          "sha256": "architecture-sha256"
        }
      }
    ],
    "custom": {
      "baseCommit": {
        "uri": "https://github.com/octocat/hello-world/commit/bf02510c8ce0b804a099797510af...c19325acfb979538c5b521304c83cde63892",
        "digest": {
          "gitCommit": "bf02510c8ce0b804a099797510af...c19325acfb979538c5b521304c83cde63892"
        }
      },
      "requirements": [
        {
          "issue": "https://octocat.atlassian.net/browse/FIN-3678",
          "title": "develop rate limit for orders"
        }
      ]
    },
    "result": "COMPLETED",
    "intents": ["develop feature"],
    "processSummary": "developed rate limiting for /api/orders",
    "owner": "me@octocat.com",
    "reviewers": ["me@octocat.com"],
    "startTimestamp": "ISO 8601 timestamp",
    "endTimestamp": "ISO 8601 timestamp"
  },
  "createdAt": "2026-04-08T08:55:17.242Z",
  "createdBy": "me"
}

Developer Velocity Meets Uncompromising Governance

Adopting an agentic SDLC does not mean choosing between speed and control. By establishing standard attestation formats for autonomous agents, organizations achieve:

Capability Benefit Example
Troubleshooting and monitoring You trace any agent session back to the commit or release it affected, and the logs are retained for the period your retention policy defines. An MCP server is disclosed as malicious. Search logs by tool, follow the commit, and identify every release that shipped it.
Policy-as-code validation You check harnesses, models, tools, owners, and outcomes against your organization’s policy before any artifact moves. A package is blocked from production because a merge commit ran on a non-approved model and has no named owner.
Human oversight You may route human review only to sessions that actually carry risk or missed oversight, not every session. 235 of 240 commits are aligned. The 5 flagged on pricing route to the pricing feature owner for approval.
Regulatory alignment You persist process logs for the retention period your policy sets, linked to the development process that created them. For high-risk AI systems, EU AI Act Arts. 19 and 26(6) set a floor of at least six months, where applicable. Missing human oversight becomes identifiable and auditable.

Ready to Secure Your Agentic SDLC?

Translating these open evidence standards into your existing release pipelines doesn’t mean building everything from scratch.

If you are an engineering organization using AI agents to write, review, test, or ship software, you need more than visibility into the final code. You need to know what the agent did, why it did it, which tools and models it used, and whether the process complied with your policies.

JFrog AppTrust already implements this evidence layer as Prompt to Release Traceability, connecting agent session logs to signed release evidence. Schedule a demo to see AppTrust in action.

This blog content is provided for general informational and illustrative purposes. It reflects information available as of the publication date shown below and may not be updated. Examples and outcomes are illustrative; actual results may vary depending on your environment and use case. JFrog makes no representation or warranty that the content is complete, accurate, current or suitable for your particular circumstances. You are responsible for evaluating the content before relying on it. This blog does not modify any agreement governing your use of JFrog products or services. Product use remains subject to the applicable JFrog Subscription Agreement or other written agreement between you and JFrog.

Popular Tags