SentnelOpsLifecycle & policy
Identity gives every agent a name and an owner. This layer decides what a named agent is allowed to become — draft, approved, active, suspended, decommissioned — and what it may do, tool by tool, in plain YAML.
Layer 1 answers "who is this agent?" Layer 2 answers the two questions that follow: what may it become, and what may it do? The first is a state machine the API itself enforces — a production agent is born as a draft and cannot run until a second person approves it. The person who created the agent can never be that second person: self-approval is rejected with a 403 segregation_of_duties, by code, not by convention.
The second question is answered in YAML. Each agent's tool-level permissions — which tools it may call on which MCP servers, and how dangerous each tool is — live in your org's own policy document, edited from the Policy page (validated on save, live within seconds) and overlaying the platform default. Risk-based review cadences then make sure nobody sets a policy once and forgets it: every agent comes up for human re-review on a schedule set by its risk level.
At a glance
| What it governs | Whether an agent may run at all (lifecycle state), what it may call when it runs (YAML tool policy), and how often a human must re-justify its access (review cadence). |
| Key objects | The lifecycle state (draft → approved → active ⇄ suspended → decommissioned), the org's YAML policy document (edited on the Policy page, over a platform default), and the per-agent review cadence (next_review, driven by risk level). |
| Where it lives | Lifecycle in the API (POST /agents/:id/approve|activate|suspend|reactivate, DELETE /agents/:id) and on each agent's detail page; policy on the Policy page (backed by GET/PUT/DELETE /policy/source), evaluated by POST /policy/check and the gateway. |
| Depends on | Layer 1 — agent identity. Every rule here keys off a registered agent: its id or name, its environment, its risk level, its creator. |
| Consumed by | Layer 3 — the gateway evaluates these policies against every live tool call; layer 4 turns the same decisions into blocks and human approvals. The rules are written once, here. |
When you need this layer
You need lifecycle the day an agent touches production: without it, whoever can create an agent can also launch it, and no auditor will accept that. You need policy the day an agent's credential can reach a tool you would not want it to call — server-level scope says "GitHub, yes"; tool-level policy says create_issue yes, delete_repo no. And you need review cadences the day your registry outgrows what one person remembers, because unused permissions do not expire on their own.
Everything in this layer works before any traffic is routed through the gateway. In layer 2 the policy engine is advisory: it returns decisions, and POST /policy/check lets you prove a policy correct before anything ever blocks. Enforcement is a later, deliberate switch.