Nobody defined what
the agents are allowed to do.
Authority should be granted, not assumed.
Most agents run with whatever permissions the person who launched them happened to hold, against whatever scope the prompt happened to imply. That isn’t a policy. It is a coincidence, and the codebase is what’s riding on it.
In ASE, roles, scopes, and gates are versioned objects — reviewable before a single agent starts.
An improvised boundary is a boundary that moves.
Nothing here requires an agent to misbehave. Every failure below happens while the agent does exactly what it was told.
The prompt is the policy.
The limits live in whatever sentence someone typed at 11pm. Nothing versions it, nothing reviews it, and nothing stops the next run from typing something different.
Blast radius nobody scoped.
An agent with repository-wide reach can refactor a module it was never meant to see, rewrite infrastructure it doesn’t understand, or apply a change no human signed — all while following instructions faithfully.
Watch the terminal and hope.
Supervision-by-scrollback works for one agent for one hour. It does not survive a constellation, an overnight run, or a second operator with different habits.
Authority as a definition, enforced at the boundary.
ASE separates what an agent may do from who happened to launch it, and writes both down where they can be reviewed.
The rules are a document, not a memory.
Problem, architecture, compliance, and constellation definitions are versioned objects. What agents may build, touch, and change is diffable before the run and attributable after it.
An agent is a role, not a login.
Each role gets its own model, harness, tool access, and work scope. The reviewer cannot merge its own work. The implementer cannot approve its own gate. Separation of duties survives contact with automation.
Human approval on the verbs that are hard to undo.
Risk-scored gates sit in front of merges, applies, releases, and exceptions. The decision, the approver, and the stated reason are captured at the moment they happen.
Issued through your IdP, not inherited from a laptop.
Keycloak provides OIDC authentication, MFA, passkeys, and role-based access control. Authority is enforced at the CLAiR boundary rather than assumed by whichever shell started the process.
Deciding the boundary before anyone runs anything.
The order matters: definition, then roles, then gates, then launch.
Define the work, not just the ask
A guided, LLM-assisted intake turns intent into versioned problem, architecture, and compliance definitions that a human reviews and signs.
Assign roles and scopes
The constellation names each agent’s role, model, harness, tool access, and the slice of work it is permitted to claim.
Set the gates that need a person
Risk scoring decides which transitions stop for human approval and which proceed on evidence alone.
Launch and supervise live
Dashboards show claims, leases, gates, branches, and failures as they happen — and the boundary holds without anyone watching.
What “who authorized this?” looks like when it has an answer.
Every item below is queryable after the fact, without asking anyone what they remember.
- Definition versions — what the agents were permitted to do, as of the version the run executed against.
- Role and scope map — which agent held which authority, with which model and harness.
- Approval record — who approved each gated transition, when, and on what evidence.
- Exception register — every override and the justification recorded at the time it was granted.
- Access decisions — identity-backed authorization events from Keycloak, tied to the run.
This one rarely shows up alone.
Define the boundary once. Enforce it every run.
We’ll model your approval structure in ASE on the call — roles, scopes, and the gates that need a human.
Elevate Your Vibe with ASE Precision.