A badge per job. Smaller at every handoff.
Five steps decide what an agent may do: issue, narrow, expire, revoke, record. In market terms, constrained delegation with an audit trail.
Issue, narrow, expire, revoke, record.
Issue
A person or an event starts a job. Ares issues a badge from what your directory says that person may do, and what the first agent needs. Nothing more.
Narrow at every handoff
When one agent hands work to another, the new badge is the overlap of the caller’s badge and what the next agent needs. It never grows.
Expire
The badge belongs to the job. When the job ends or the time runs out, it stops working. No standing access is left behind.
Revoke
Decommission an agent and its badges stop working at the door, mid-job if needed. The revocation is on the record.
Record
Every issue, handoff, refusal and revocation is written as it happens, into a record nobody can quietly edit.
Some steps wait for a person.
Four kinds of step wait for a person by default: widening a badge, touching another agent’s identity, reaching a higher-tier system, and keeping data beyond the job. You can add more. The answer is written down like any other decision.
- Widening a badge
- Touching another agent’s identity
- Reaching a higher-tier system
- Keeping data beyond the job
What the record holds
For each step: which agent acted, for whom, under which badge, what the badge allowed after narrowing, what was refused or redacted and why, who approved, and when. For any step you can trace back to the person or event that started the job, and forward to every handoff after it.
What is planned
- A named owner and review date for every agent. Today each agent is tied to an owning group in your directory.
- Revoking a whole job’s badge tree in one action.
- Exporting a badge in open credential formats, and a replay tool your auditor can run without us.
What architects ask about the model.
Take the model into your review.
The security pack shows the model at the depth this page leaves out. We send it after a short NDA.