PPromptReports
Sign in
Use cases/Contain an agent that went wrong/OpenSpec plan

Plan: Contain an agent that went wrong

Proposedopenspec/changes/wf-contain-an-agent

Written for an AI agent to fetch and follow: it says what to connect, which steps to build with which product, what a person must approve, and how to check the result. Steps that depend on a part that is not built say so, and tell the agent to record the gap instead of guessing.

Raw URL: https://promptreports.ai/use-cases/contain-an-agent/openspec.md

URL pattern: /use-cases/<id>/openspec.md, all plans at /use-cases/index.json. Checkboxes on this page are for reading only.

openspec/changes/wf-contain-an-agent/proposal.md

Why

When an agent misbehaves, teams cannot see what it touched, and they rotate keys in each tool by hand while it keeps running. Agents now hold more credentials than people. Containment needs to take minutes, not an afternoon of tabs.

What Changes

  • Add the contain-an-agent workflow to the PromptReports workflow library, run by the workflow runner as an agent acting for a person.
  • PromptCompute: Revoke the agent version and its grants (today: Built).
  • RepoOps: List what it touched (get_agent_blast_radius) (today: Built).
  • CommitOps: Revoke its CommitOps credential (today: Built).
  • PromptCompute: Revoke its tokens in every other product (today: Planned).
  • RepoOps: Open an incident and a lesson (today: Built).
  • Gate access.revoke, repoops.request_key_rotation, commitops.credential.revoke through PromptCompute approvals; each gated step runs only after verifyResume passes, with final_args.
  • Write a signed record at the end of each run and count one workflow request.

Impact

  • Products: PromptCompute, RepoOps, CommitOps, ContextFile.
  • Outside the family: GitHub, Your cloud provider (optional).
  • State: Proposed. Not in the plan. Needs ID agent tokens accepted everywhere (LDG-2264, Planned).
  • Plan row: none yet (Proposed).
openspec/changes/wf-contain-an-agent/tasks.md

1. Connect and authorize

  • 1.1 Confirm the org has a connection for each of: PromptCompute, RepoOps, CommitOps, ContextFile. Stop and tell the user which is missing.
  • 1.2 Get a PromptReports ID agent token for each product the run calls (RFC 8693 exchange). Where a product does not accept ID tokens yet, use its connect key.
  • 1.3 Register policy for access.revoke, repoops.request_key_rotation, commitops.credential.revoke with require_approval as the default.

2. Build the steps

  • 2.1 PromptCompute: Revoke the agent version and its grants.
  • 2.2 RepoOps: List what it touched (get_agent_blast_radius).
  • 2.3 CommitOps: Revoke its CommitOps credential.
  • 2.4 PromptCompute: Revoke its tokens in every other product. Blocked: this part is Planned; until it ships, record the step's evidence as missing and continue.
  • 2.5 RepoOps: Open an incident and a lesson.

3. Verify and record

  • 3.1 Run a dry run with the user's inputs: Agent = agt_...; Version = agv_... or all versions.
  • 3.2 Run it once for real; approve each gate as the user.
  • 3.3 Measure the outcomes: Minutes from trigger to revoked in every product; Products that confirmed revocation: target all; Actions found in the blast radius.
  • 3.4 Confirm the run left a signed record with a task id and one workflow request counted.
openspec/changes/wf-contain-an-agent/specs/workflow-contain-an-agent/spec.md

ADDED Requirements

Requirement: Revocation is confirmed per product

The workflow SHALL record a confirmation from each product that the agent's tokens no longer work.

Scenario: Revocation is confirmed per product

  • WHEN a product still accepts the token after revocation
  • THEN the run marks it missing and pages the owner

Requirement: Evidence stays honest

Each step SHALL report what it saw as measured, inferred or missing, and SHALL never report missing as measured.

Scenario: A product part is not built

  • WHEN a step depends on a part that is Planned or Proposed
  • THEN the step records missing, names the part, and the approval card shows the gap

Requirement: One run is one workflow request

The runner SHALL count one workflow request when the first step starts, and SHALL NOT count retries, resumes or dry runs.

Scenario: A gated step resumes after two days

  • WHEN a person approves a step and the run resumes
  • THEN the org's usage does not change