Enterprise · Agent Governance

Your agents have names, owners
and an off switch.

By 2027 it’s fleets — and a fleet of anonymous processes is a liability. LeanCTX makes every agent a registered identity: unique, owned by a human, lifecycle-managed, attested and revocable — with every transition in the tamper-evident audit trail.

The model

Identity is who answers. Role is what runs.

Roles stay reusable permission profiles. Identity attaches accountability on top: agent_id, owner, status, key binding, attestation, heartbeat. Four properties make a fleet governable.

Registered identity

Every agent is a record: stable agent_id, role, Ed25519 key binding, creation date. No more guessing which process did what — the registry is the source of truth for who exists.

Owned, always

Registration without a human owner is rejected. Accountability is structural: every audit entry, every lifecycle event, every evidence bundle traces to a person who answers for the agent.

Revocable in one transaction

Suspend an agent, or offboard an owner and suspend their whole fleet atomically — each suspension individually audited. Decommissioning is final and writes the audit-closing entry.

Attested, honestly

Binary and role-config hashes at registration and every heartbeat. Drift surfaces immediately (exit code 3) — upgrade, config edit or tampering. We document what this does NOT protect against.

In practice

A fleet, five commands.

Everything is CLI-first and exit-code honest, so your pipelines and your monitoring can act on it.

$ lean-ctx agent register --id ci-reviewer-1 --role reviewer --owner alice@org
registered: ci-reviewer-1 (role reviewer, owner alice@org)
spiffe id: spiffe://org.example/agent/reviewer/ci-reviewer-1

$ lean-ctx agent heartbeat ci-reviewer-1     # liveness + drift; exit 3 on drift

$ lean-ctx agent offboard-owner alice@org --reason "left company"
suspended 2 agent(s): ci-coder-1, ci-reviewer-1

$ lean-ctx agent check ci-reviewer-1         # enforce-path decision point
ci-reviewer-1: DENIED — suspended: left company   # exit 1

Every transition writes a tamper-evident audit entry — registered, suspended, resumed, decommissioned are standardized event types (OCP Part 4), so identity history lands in your evidence bundles automatically. Full model and threat model: agent-identity docs.

"What happens when someone leaves?"

Their agents stop. Mechanically. Owner offboarding suspends every active agent of that owner in one locked transaction — wired to your SCIM deprovisioning flow or run from the leaver checklist. Orphaned agents are the forgotten service accounts of the agent era; LeanCTX makes them structurally impossible.

FAQ

What platform teams ask.

Why do agents need identities when they already have roles?

A role says what a process may do; an identity says who is accountable for it. With fleets, the questions that matter are operational: who owns this agent, when was it last alive, who switched it off and why, what happens to its permissions when its owner leaves? The registry answers them mechanically — identity (who) stays separate from role (what), so roles remain reusable profiles.

What is the orphaned-agent problem?

An agent whose human owner left the company but which keeps running with its credentials — the agent-era version of the forgotten service account, except it reads code and runs commands. LeanCTX closes it structurally: owners are mandatory at registration, and one command (or your SCIM deprovisioning flow) suspends an owner’s entire active fleet in a single locked transaction, every suspension audited.

How does the lifecycle work?

active → suspended ⇄ active → decommissioned. Suspension carries a reason and is reversible; decommissioning is final by design — the record is never deleted and never reactivated, because the identity is part of the audit history. Every transition writes a tamper-evident audit entry using standardized event types (agent_registered, agent_suspended, agent_resumed, agent_decommissioned — OCP Part 4), so identity changes show up in evidence bundles automatically.

What does attestation actually prove?

Registration and every heartbeat hash the running binary and the active role file. A changed hash means something changed — an upgrade, a config edit, or tampering — and surfaces as drift with a non-zero exit code your monitoring can alert on. It is drift detection, not remote attestation: an attacker with full host control can fake hashes, and our threat model says so explicitly. It complements, not replaces, host hardening and code signing.

How does this integrate with our IAM?

Three hooks. SPIFFE: every record maps to spiffe://<trust-domain>/agent/<role>/<agent_id>, so K8s workload identity (SPIRE) and the LeanCTX identity are the same name. SCIM: wire your deprovisioning flow to the owner-offboarding call. Enforce mode: the check API is a single decision point — unregistered or suspended agents are denied; start in monitor mode, switch to enforce once the fleet is registered.

Govern the agent workforce.

Register your first agent in a minute, locally and free — or talk to us about fleet rollout with SCIM and SPIFFE in the loop.