Organizational structure has meaning.
It shapes how decisions flow, who holds authority, and how quickly change can happen, so when you layer agentic AI on top of an existing organizational model, the fit is either natural or deeply awkward.
Many teams treat AI adoption as a technology problem, but it's at least as much an organizational one.
The structure you already have decides which access models work, which approval patterns break, and whether agents become accelerators or bottlenecks.
How the common organizational types handle agents
Organizational structures cluster into a few familiar patterns, and each makes different assumptions about delegation, decision-making speed, and who owns what.
Underneath all of them sits the same question: how do you deliver self-service speed while keeping the oversight that security and privacy require?
That tension isn't new, but agentic AI gives it new urgency, because agents act quickly, continuously, and across boundaries that were drawn for slower human work.
Structure is one axis of the answer, where an agent sits relative to the people it works with is another, and the two interact.
Flat organizations
Flat organizations distribute decision-making widely, with few approval layers between people and outcomes, so agents seem to fit naturally: fast, distributed action is already the norm.
This is probably the natural home for the most common arrangement today, one or more agents working for an individual, since people here already act with little gatekeeping.
But the same freedom turns into access sprawl, because agents move fast and have no natural brakes.
The speed is already there, and what's missing is policy expressed clearly enough to act as a guardrail.
Functional organizations
Functional organizations group people by expertise, with clear boundaries and a leader for each function.
That gives strong ownership and natural enforcement points, but work that crosses functions has to move through handoffs.
A data analyst who needs database access already runs into this today, with the data owned by engineering and provisioning controlled by operations.
The difference is that a person copes by collaborating, asking around, finding the right owner, and waiting it out, and the organization trusts that to end inside the boundaries it cares about.
An agent is held to a narrower, more controlled path, partly because of hallucinations and the harness it runs inside, and partly because an agent can get too focused on finishing its task at any price, which is a shortcut nobody would trust a colleague to take either.
So a boundary that only slows a human down can stall an agent completely.
Divisional organizations
Divisional organizations run as semi-autonomous business units, each with its own P&L.
Agents operate easily inside a division and fragment across them, because there's little incentive to share infrastructure, so each division deploys its own agents for similar work and nobody has a company-level view of which non-human identities exist.
Within a single unit, an agent often serves the whole team as shared support rather than one person, which only stays manageable when the unit names a clear owner for it.
Local control is good, but consolidated governance is missing.
Matrix organizations
Matrix organizations layer functional expertise over business units and are built for crossing boundaries, so agents move freely because the model already assumes people do.
The cost is that nobody owns anything cleanly, so when an agent misfires or its access is misconfigured, accountability and forensics fall between the cracks.
Network organizations
Network organizations replace permanent reporting lines with dynamic project allocation, forming teams around outcomes rather than org charts.
Agents fit naturally here too, because autonomous execution is already expected, and it's where an agent is most likely to join a project team as another member, an n+1 on the roster.
But without stable roles and a recorded owner, access becomes nearly impossible to audit, so governance has to be designed in deliberately.
A model that adapts to the structure you have
The lesson across all five is that you can't transplant a generic access framework onto an organization and expect it to hold.
Access governance has to follow the shape the organization already has, because that shape is what tells you where speed should be free and where oversight has to sit.
How to get that balance right is at the core of what we work on at Accession1, so take this as a snapshot of current thinking rather than a settled design.
Our working assumption is that access should be modeled on the organization as it actually operates, not on a separate access hierarchy that drifts away from it over time.
The pieces involved are deliberately ordinary.
The identity provider stays the system of record for identities, human and non-human alike, and those identities arrive as subjects carrying the attributes it already holds.
Workspaces group work and are flexible on purpose: one per team, one per project, one per business unit, whatever matches how the organization divides itself.
Resources are the concrete instances provisioned in target systems, a Slack channel, a GitHub repository, a Kubernetes namespace.
And access packages are where access is decided, binding identities to resources at a given role.
The connective tissue is labels, and they come from more than one place.
Some are inherited: a subject carries the department, team, role, or location its identity provider already knows, and a resource carries the labels of the template it was provisioned from.
Some are set by whatever manages the model, such as which workspace an object belongs to.
And everything can carry custom labels, which is where an organization's own taxonomy lives: a privacy classification, a security tier, the business domain a resource belongs to.
An access package uses label selectors that can combine all of these to find the relevant identities and the relevant resources, and grants a role between them.
A grant produced this way is dynamic rather than static.
It exists while the selector matches and disappears when the match ends, which is what turns a reorganization into a policy edit instead of a migration project.
Where the boundary sits
The first place the organizational type shows up is in how workspaces are drawn.
A divisional organization leans toward a workspace per business unit, a functional one prefers one per function, and a network organization spins one up per project, and mixed arrangements such as a business unit subdivided by function are easy to imagine.
That placement isn't tidiness on an org chart, because it settles a tradeoff that self-service otherwise leaves open.
Self-service exists so work can move at the pace of the people doing it, without routing every request through a central queue, but some oversight isn't optional, because security and privacy obligations don't disappear when access gets faster.
The workspace is a natural place to draw the line between the two: IT and security own the boundary, meaning which identities are eligible to be granted anything inside it at all, and the people working inside it own what happens within it, granting access quickly among the resources and identities that already belong there.
In practice both the boundary and the matching inside it are the same kind of label constraint, and what differs is where the selector comes from and who controls it.
A workspace carries a selector set by IT or security, for example one admitting only identities whose business unit matches the workspace.
Every access package created inside it inherits that selector, and members can't remove or loosen it, because selectors are cumulative: a member's own selector narrows the set further and never widens it past the workspace boundary.
That's the guardrail security teams have been missing, because they set it once, at the level where the workspace sits, and self-service then operates inside it rather than against it.
Consider a legal team responsible for employment contracts, documents that can't be exposed to just any identity in the company.
If the legal workspace is scoped so access can only be granted to identities whose function attribute is set to legal at the identity provider, the constraint holds no matter who is configuring the access.
An engineer can't be added by mistake, and an agent built to support a different team can't be selected into a contract-handling access package, because it doesn't carry the required attribute.
The sensitive boundary is enforced by the shape of the organization and where the workspace sits in it, not by the attention of whoever happens to be granting access that day.
Which label decides
Our first instinct, and this is still an open question for us, is that each structure has one decision point that matters more than the rest: the function in a functional organization, the business unit in a divisional one, the assigned owner in a matrix, the active project in a network.
Where the label capturing that decision point is present and accurate, an access package can express the rule in the organization's own terms, and the same mechanism adapts across structures because the only thing that changes is which label does the selecting.
Combining labels
A single label answers a single question, but a combination of labels, from more than one source, can describe an access pattern that mirrors how the organization actually wants to work.
Take internal collaboration.
Resources can carry a visibility label from the organization's own taxonomy, so a repository meant for open internal contribution is marked innersource, and subjects carry a function label inherited from the identity provider, so engineers are marked accordingly.
An access package can then say that every subject whose function is engineer gets read and comment access to any resource whose visibility is innersource.
The rule is written once, in the organization's own terms, and keeps applying as people join and repositories are created, without anyone maintaining a list.
The label taxonomy this depends on
There's an honest dependency here, because label selectors are only as good as the labels behind them.
Dynamic access management depends on one label taxonomy shared end-to-end, which means identity provider attributes, the organization's custom labels, access package selectors, and the labels on resources in target systems all use the same keys and the same values.
A derived grant exists only while a selector matches, so a department spelled one way on a subject and another way on a resource produces no grant at all, and a label that drifts out of the taxonomy silently revokes access, or silently extends it.
Neither failure announces itself, which is what makes this the part worth being careful about.
Keeping the taxonomy consistent is ongoing discipline rather than a setup step, and it's where we think AI is genuinely useful, less as a headline and more as a practical tool.
The work is categorizing unstructured information: surfacing the attributes that already exist across identity sources, reconciling the ones that mean the same thing under different names, applying the organization's own taxonomy the same way in every workspace, and flagging entries that no longer fit when the organization changes.
That's what language models are good at, and the first payoff is a clearer view of the organization, with accurate access following from it.
The reverse is worth stating just as plainly.
AI behaves non-deterministically, which is exactly why it has no business deciding grants or executing reconciliation.
Evaluating selectors, building the resulting set of grants, and applying them to target systems has to be deterministic, so the same identity, resource, and policy state always produces the same access.
AI assistance belongs in the modeling work that humans review and commit, not in the path that grants access.
Facts that only matter together
Something else has surprised us: how much context a boundary decision needs, and how unrelated most of that context looks on its own.
The share of contractors in a team says nothing about access by itself, and neither does the country an office sits in or the fact that two business units are separate legal entities.
Read together, they decide the design.
A team that is largely contractors and handles customer data under a residency mandate needs a tighter boundary and a higher risk tier than a team of employees doing the same work on public data, and two business units that are separate legal entities need separate workspaces, with a joint venture between them getting its own.
So the model behind access has to record more about an organization than its reporting lines, it has to read those facts in combination, and it has to keep reading them as they change.
Where this leaves us
Organizational structure isn't a backdrop to access control.
The two are closer than they're usually treated, and organizational design and identity governance are really two views of the same problem.
Each structure draws its own boundary and carries its own decision points, and agentic AI raises the stakes by acting fast, continuously, and across lines drawn for slower human work.
The thread running through our approach is labels.
A workspace boundary set by IT, an access package's own selector inside it, and access rules built from combinations of inherited and custom labels are the same mechanism at different scopes.
Get the label taxonomy right, and access can follow the organization as it actually is, and keep following it as it changes.
We're sharing this because it's how we currently think about the problem, not because it's finished.
The mapping from structure to decision point, inheritance of constraints down a hierarchy, and the role of AI in keeping the taxonomy consistent are all still open, but the shape of the question isn't: balancing speed against security and privacy, now at agentic speed, is the part that won't go away.
Top comments (0)