AI agents turn excessive permissions into active risk
IT and security teams granted roles whole long before the first agent. A person had a wide range of tasks, so pinning access to exactly those tasks was hard, and the narrower role took a project while the ticket was due that day. Access policies were written far from the work, by a central team without insight into what a day in finance or legal touched, so they erred on the side of not getting in the way. Privilege creep did the rest: a role, once assigned, stayed until a review happened to catch it. The teams that ran it kept a list of the privileged roles, reviewed what they could, and carried the rest as residual risk.
That risk was tolerable while people held the excess, because a person rarely touched it. An agent handles tasks as wide-ranging as a person’s, gets none of a person’s trust, and can exercise any permission it holds, including after a prompt injection. So least privilege stopped being a principle to aspire to and became the condition for letting an agent in. In an agentic organization a team adds agents faster than any review trims what they inherit.
Accession1 is self-service provisioning of resources and access for people and AI agents. Workspace members grant the roles their work needs inside boundaries administrators set, and Accession1 revokes them when the reason ends.
Least privilege designed where the work is known
Access designed from the org chart comes out generic. A baseline by job title fits nobody’s actual work, so it comes out too wide to be safe or too narrow to work, and the wide version wins. In Accession1 the access policies are written in the workspace, by the people who know who does what, through self-service provisioning. The AI assistant brings the context and the practice of least privilege to the workspace member writing the rule, because workspace members can’t be expected to be IAM experts. An agent’s baseline comes from its placement: one level below its owner’s, read-only where the owner writes, and never a role its owner lacks.
The risk tier of each template, from system criticality and data sensitivity, draws the line a rule can’t cross, and a critical system gives an agent less than a routine one. The rules administrators set through context-aware design are the ceiling, and nothing a workspace member or an agent creates reaches past them. Continuous reconciliation applies the rules on every change, in every system a module connects. So fine-grained access built for one purpose is no longer too much work to maintain, and too much work is the reason it was never kept before.
Just-in-time elevation and break-glass access
Least privilege by rule leaves the one-offs. An engineer needs a privileged role for one release, a records manager reopens a closed client file for one subpoena, and an agent’s task needs a role its standing access doesn’t include. Those used to be the tickets that granted a role whole and never took it back, or the standing administrator account everyone shared for emergencies.
In Accession1 each is a just-in-time (JIT) elevation, a temporary grant with an end date on top of what the graph derives. The same reconciliation that follows labels removes the grant on that date, with no label change needed, so the elevation never outlives the change it was requested for. It is one mechanism for a person, an agent, and an incident, requested in self-service inside the workspace, so the request never becomes a ticket and the grant never becomes standing access. The industry sells just-in-time access as a product of its own. Here it is the exception path of the same access graph, written on the same context and labels as everything else, so an elevation reaches nothing the administrators’ rules keep out.
An incident needs access faster than any approval, and most organizations keep a shared emergency account for it. In Accession1 break-glass access is the emergency path of just-in-time elevation, the same mechanism with a shorter route. It is granted to one identity, recorded as a grant with its reason, and expires like any other elevation. A clinician reaching a record outside the ward and an on-call engineer reaching a production database at night go through the same door. The review afterwards reads the grant instead of a vault log.
A human in the loop where the risk calls for one
Who approves an elevation follows from the risk tier of the target system, not from who happens to be on the queue. The elevation policy, written by administrators on the same context and taxonomy as everything else, approves low-risk requests automatically against the rules, routes mid-risk ones to a workspace peer, and sends high-risk ones to a tenant administrator. So the human in the loop is there where it matters and absent where it would only slow the work down. The AI assistant never takes that decision. It helps write the elevation policy and answers questions about the elevations in effect, and reconciliation applies the result deterministically.
Why access requests and right-sizing fall short
A request grants a role whole, and revoking it takes a request of its own, which rarely follows. A timer ends it on a date instead of with its reason, so the next task asks again. Right-sizing from a usage report trims what wasn’t used and keeps what was. Identity security posture management (ISPM) and cloud infrastructure entitlement management (CIEM) tools arrive at least privilege this way. The pilot’s shared token survives because an agent still calls it, and a new agent with no usage to derive from falls back to a ticket. Those tools don’t provision the access, so they infer what it should be from activity after the grants were made. In Accession1 the graph is designed and drives the access, and the change is the trigger. A rule gives an identity what its place and purpose call for the moment it exists, and an elevation ends when its time does. Relabeling a resource, retiring an agent, or deactivating a leaver in the identity provider revokes the grants in every target system in the next reconciliation. Why that holds against both alternatives is the three ways to decide access.
Less attack surface, smaller blast radius
Every standing role nobody needs is a way in for whoever obtains the credential. Everything a compromised identity can reach is its blast radius. Least privilege by rule shrinks both, for a person who rarely touches the excess, for a service account whose key outlives its project, and for an agent that can exercise anything it holds. An elevation that expires leaves no privileged role behind for the next prompt injection to find. The next access review reads the rules and the elevations in effect rather than a list of standing roles. If the forecasting agent is compromised tomorrow, it exports nothing, because no rule gives it the export, and the elevation it held for this morning’s task has already expired.
