LAYER 2 · LIFECYCLE & POLICY

Lifecycle & policy guides

Four tasks you will actually do: launch a production agent the compliant way, write your first tool-level policy, suspend and reactivate safely, and run an access review. Each works from the dashboard or with curl.

Take a production agent from draft to active

This takes two people, on purpose. A production agent registers as draft (see layer 1 for registration itself); the creator then hands off to a second person with the security role.

Person 2 approves. In the dashboard: open the agent's detail page and click Approve. With curl:

Person 2 — must NOT be the creator (min role: security)

curl -X POST https://api.sentnelops.com/agents/AGENT_ID/approve \
  -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"approved_by": "reviewer@example.com", "note": "reviewed scope, LGTM"}'

If approved_by matches the creator, the API returns 403 segregation_of_duties — there is no override.

Then anyone activates. Activation is the low-ceremony step (min role developer) — the control was the approval:

approved → active

curl -X POST https://api.sentnelops.com/agents/AGENT_ID/activate \
  -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"actor": "creator@example.com"}'

Trying to activate straight from draft returns 409 approval_required. Dev and staging agents skip all of this — they register directly as active.

Write your first tool-level policy

Open the Policy page in the dashboard (min role security) — it starts you from the platform default. Add a block keyed by the agent's id or name, starting from what the agent actually needs and letting deny-unlisted catch the rest. (Self-hosted, you can instead keep the default as a YAML file in the policies directory.)

policies/my-first-policy.yaml

policies:
  defaults:
    deny_unlisted: true         # anything not in an allow list is denied

  my-agent-name:
    github-mcp:
      allow: [read_file, list_repos, create_issue]
      deny: [delete_repo, force_push]
      blast_radius: {delete_repo: 0.9, force_push: 0.7, read_file: 0.1}

deny beats allow, and with deny_unlisted: true (the shipped default) any tool in neither list is denied — so the deny list is really documentation of the tools you considered and rejected. blast_radius scores (0.0–1.0) label how destructive each tool is; they ride on every log row and later drive layer 4's approval trigger. Click Validate, then Save policy — the change is live within ~5 seconds — then prove it before the agent runs:

Advisory check — decides, never blocks

curl -X POST https://api.sentnelops.com/policy/check \
  -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"agent_id": "AGENT_ID", "mcp_server": "github-mcp", "tool": "delete_repo"}'

# → {"permitted": false, "reason": "tool delete_repo is denied on github-mcp",
#    "agent_id": "AGENT_ID", "policy_rule": "github-mcp.deny"}

Suspend and reactivate an agent safely

Suspension is the incident brake: the agent immediately fails every policy check (and therefore the gateway), but its configuration and audit history stay intact for the investigation. A reason is mandatory — it becomes part of the permanent record. Dashboard: Suspend on the agent detail page. Curl (min role security):

active → suspended

curl -X POST https://api.sentnelops.com/agents/AGENT_ID/suspend \
  -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"actor": "security@example.com", "reason": "anomalous call volume, ticket SEC-123"}'

While suspended, edits to allowed_mcp/denied_mcp are rejected with 409 scope_frozen — resolve the incident first, then change scope. When you are satisfied:

suspended → active (within 30 days)

curl -X POST https://api.sentnelops.com/agents/AGENT_ID/reactivate \
  -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"actor": "security@example.com"}'

A suspension older than 30 days cannot be reactivated (409 reapproval_required) — the agent must go back through /approve with a fresh second person, then /activate. If an agent stayed suspended that long, treat it as new.

Run an access review

The overdue queue is simply every agent whose next_review has passed — the dashboard and the governance report both surface it. For each agent, re-read its scope and policy entry, confirm the owner still stands behind it, then record the review (dashboard: Mark reviewed; min role security):

Record a completed review

curl -X POST https://api.sentnelops.com/agents/AGENT_ID/review \
  -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"actor": "security@example.com"}'

This sets last_review to now and advances next_review by the risk cadence (high 30d / medium 90d / low 180d). The daily sweep does the flagging side: it writes one review_overdue audit event per missed deadline and one expired event per agent past its expires_at — once per deadline, not once per day, so the audit log stays readable. If a review concludes the agent should not exist, decommission it instead: DELETE /agents/AGENT_ID revokes its tokens and closes the record permanently.

Next: Reference