Many organizations adopting AI agents seem to sit somewhere between a few pilots and a handful of agents doing real work inside one department. The agentic organization, where people and agents share work end to end, is further out, and the distance is usually described as a question of models, data, and tooling. I think the harder part is the boundaries inside the organization itself. Some of the slowest processes today are the ones that cross teams, functions, and legal entities, and an agent that gets stuck at the same boundaries a person does is unlikely to make them much faster. So before access control can let agents through, it has to understand where those boundaries are and why they exist.
This is a question we spend a lot of time on at Accession1, so take what follows as current thinking rather than a finished answer.
What an agentic organization actually is
The term describes an operating model more than a technology. Instead of adding AI to a process people already run by hand, the process is designed on the assumption that agents do most of the execution, while people supervise, decide, and handle the exceptions. Even modest versions of this are likely to multiply the number of identities an organization has to govern. A team of five working with a few dozen specialized agents could hold several times as many identities as it has people, and each one needs its own access, its own owner, and a lifecycle that probably changes faster than headcount does.
None of those agents appears on an org chart, which is why some people suggest replacing the org chart with a work chart, a map of who and what contributes to an outcome instead of who reports to whom. I’m not sure the org chart goes away, because legal structure, budgets, and accountability still follow reporting lines, so many organizations may well use both side by side.
The maturity models on offer
Several maturity models for agentic AI have appeared in the last year and a half, and none of them is a standard yet. Most come from vendors describing the path their own products support, and the rest are drafts or research proposals, so they’re worth reading as a set of perspectives rather than a yardstick.
Salesforce’s agentic maturity model is about what agents do, from FAQ chatbots up to multi-agent orchestration across different vendors’ stacks. Microsoft’s agentic AI adoption maturity model is about the organization around the agents, scoring the five levels of the classic Capability Maturity Model against strategy, process, governance, technology, and culture. The Cloud Security Alliance’s agentic AI governance maturity model, still a draft, looks only at governance, and the first of its seven dimensions is agent identity. And from research, Feng, McDonald, and Zhang define five levels of autonomy for a single agent by the role the person keeps, from operator to observer.
Read side by side, they agree on more than their names suggest. Organizations start with experiments, move on to AI that makes individuals faster while the processes around them stay the same, and then put agents into real operational processes inside one domain. The step after that is where the models converge most clearly: agents start working across several domains, which Salesforce draws as the line between single-domain and multi-domain orchestration and Microsoft places at its capable level. Every model also has a top level describing an agent-first organization, and I’m skeptical of those, because they read more like a direction than a place anyone has arrived. But the step from one domain to many is real, and it’s where work starts crossing organizational boundaries.
Where work slows down today
Many of the processes that matter most don’t follow the org chart. Closing the books at quarter end, shipping a product change that needs a legal review, and responding to a security incident all pass through several teams, often several functions, and sometimes several legal entities. At every boundary the work changes hands, and someone has to pick it up and get access to what they need to continue. In my experience, those handovers often take longer than the work on either side of them.
So the promise of agents looks obvious: if agents run the steps, the process should run at the speed of the steps. But an agent that reaches a boundary faces the same question a person does, which is whether it may act on the other side and who decides. If the answer is a handover to a person and a wait, the process likely stays about as slow as before, with faster steps between the waits.
It’s a fair argument that people are better at this than agents. A person who’s stuck asks around, finds the right owner, explains why they need something, and uses judgment about what’s reasonable to ask for. An agent is held to a narrower path, for good reasons, because of hallucinations, prompt injection, and the harness it runs inside, which means a boundary that slows a person down can stop an agent completely. And giving agents broad access to get past that mostly trades the waiting for a larger blast radius.
What we mean by context-aware
We think the way through is access control that understands the organization well enough to decide at the boundary without a handover. By context-aware we mean something specific: it understands how the organization creates value, how work actually gets done, how the organization functions, where an identity sits in all of that, and what that identity is responsible for. Access decided this way follows from an identity’s place in the organization, and it changes when that place changes.
That definition doesn’t distinguish between people and agents, and we think it shouldn’t. An employee, a contractor, a partner, and an AI agent all sit somewhere, work toward some outcome, and answer to someone, so an agent is a non-human identity with a recorded owner, and its access comes from the same model as everyone else’s. Treating them the same doesn’t mean granting them the same, though: an agent can sit exactly where the person it works for sits and still get a narrower scope, because its responsibility is narrower.
Org chart, work chart, or both
It’s tempting to ask which chart access should follow, but I don’t think that’s the question that matters. A functional org chart tells you who owns a system, a work chart tells you who needs it for an outcome, and the legal structure tells you whether data may cross between two entities at all. Access control needs all three views, and underneath them the thing it actually needs is an understanding of how the organization functions, whichever charts the organization uses to describe itself.
So the hard work shifts from approving access to modeling the organization, and that’s where we spend most of our time.
The first is which facts decide where a boundary belongs. Many of them look unrelated to access on their own: the share of contractors in a team, the country an office sits in, whether two business units are separate legal entities. Read together they can decide the design, because a team that is mostly contractors handling customer data under a residency mandate likely needs a tighter boundary than a team of employees doing the same work on public data.
The second is what an identity’s responsibility actually is. For a person, the job and the team usually say enough. For an agent it depends on whom it works for, and an agent supporting one engineer, one serving a whole team, and one running a step in a process that spans several teams need different owners and different reasons for their access.
The third is what sits on the other side of a boundary. How sensitive the data there is and how critical the target systems are decides whether an agent may cross on its own, needs someone in the team to agree, or needs an administrator, and just-in-time elevation that expires on its own keeps the exceptions from turning into standing access.
The last is change. Organizations reorganize and agents get repurposed, so a model that’s accurate on the day it’s built can be out of date within months unless it follows the organization, and access derived from it is only as accurate as the label taxonomy it reads.
Agents helping with the problem agents create
The more complex the organization, the harder this model is to build and keep current by hand. The facts are scattered across the identity provider, HR systems, contracts, regulatory obligations, and the way teams describe their own work, and most of it is unstructured. Collecting those facts, reconciling attributes that mean the same thing under different names, proposing where boundaries belong, and flagging where the model no longer matches the organization is the kind of work language models are good at. I like the symmetry of it: agents could help with the problem their own adoption creates.
But how matters as much as whether. AI behaves non-deterministically, which is exactly why it has no business deciding grants. So AI assistance belongs in the modeling: it proposes, a person reviews and approves every boundary, and the step that turns the approved model into access stays deterministic, so the same identity, resource, and policy state always produces the same result.
Where to start
If agents in your organization work inside one domain today, and the plan is to connect them across several, pick one slow process that crosses boundaries and map where it changes hands. For each handover, write down what a person needs to know to decide whether an identity may continue on the other side: whose work it is, where the identity sits, what it’s responsible for, and how sensitive and how critical the things beyond the boundary are. If that knowledge only lives in people’s heads, agents are likely to stop at that boundary or cross it with access nobody can justify. Writing it down is the start of the model access control needs, and it’s the same model for people and agents alike.