The AI Workforce: One Agent Per Seat, and the Permissions Problem Nobody Solves

An AI workforce is a group of AI agents that each hold a named role, their own credentials, and their own scoped access to company systems, instead of one shared assistant that everyone talks to. The seat is the unit, not the chatbot. Get the seats wrong and you have not built a workforce, you have built one account with a friendly interface.

We run 16 agents internally. On 30 July 2026 we found that three of them could read each other's credentials, and the fix took a rebuild of how each agent is identified. This post is what that cost us and what we now do differently.

What is an AI workforce?

An AI workforce is a set of role-scoped AI agents that carry out defined jobs inside a business, each with its own identity, permissions and audit trail. It differs from a copilot, which assists one person on request, and from a chatbot, which answers questions. A workforce agent owns a job and acts on systems.

The practical test is whether you can name the seat. "Our AI" is not a seat. "The agent that reconciles supplier invoices, reads the accounting ledger, and cannot see payroll" is a seat. If you cannot write that sentence for every agent you have deployed, you do not yet know what your agents can reach.

Three things separate a workforce agent from an assistant:

• A named role with a written authority list, so the scope is a decision someone made rather than a side effect of the tools you connected.
• Its own credentials, so actions are attributable to that agent and revocable without touching the others.
• Enforcement that lives outside the agent, so the agent cannot widen its own access even if it is convinced it should.

Most "AI workforce" products on the market solve the first point and skip the third. That gap is the whole subject of this post.

Why is shared access the real risk in an AI workforce?

Because permissions granted to a group of agents collapse to the permissions of the most privileged one. If four agents share a login, a folder or an operating-system identity, then every agent effectively holds the highest access in that set. The access control you wrote still exists. It is just no longer the thing deciding what gets read.

This is documented risk, not a hypothetical. In the OWASP Top 10 for LLM Applications 2025, Excessive Agency ranks sixth of ten, and the entry describes the failure precisely: an LLM extension "designed to perform operations in the context of an individual user accesses downstream systems with a generic high-privileged identity." One shared identity doing work on behalf of many roles.

We hit it ourselves. Our agents had correct, per-role access rules held on the host, outside the agents' reach, and those rules worked when tested. What we had missed was that three agents were running in one container under a single operating-system identity. File permissions on each agent's own directory isolated nothing, because one user owned all of them. Any of the three could read the others' configuration, including a single environment file holding 47 credentials.

The part that changed how we think was not the file access. It was the identity. Asking the data store "who am I" from inside the wrong agent returned the founder profile, with read access to everything. The rule set answered honestly. It simply was not us asking. That is identity theft between agents, and no amount of correct policy fixes it, because the policy was never consulted under a false name.

The fix was structural: each agent moved to its own container and its own operating-system identity, with each one able to see only its own files. Two independent barriers rather than one, so a mistake in either still leaves the other standing. The access rules did not change at all. They finally became enforceable.

One belief we had written down and had to retract: we had recorded that restricting an agent to a messaging channel made it safe, on the grounds that credential isolation was fail-closed. That was wrong, and being wrong in writing is why it went unnoticed for weeks. An agent with a terminal holds that terminal no matter which interface you speak to it through. Restricting the interface cannot contain a shared trust domain.

What does one agent per seat actually mean?

One agent per seat means every agent maps to a single job with a single authority list, the same way a job description maps to an employee. The seat defines what the agent may read, what it may change, and what it must never touch, and that definition is enforced somewhere the agent cannot edit.

Seats are worth the effort for a reason that has nothing to do with security theatre. They make the blast radius knowable. When something goes wrong, and it does, you need to answer two questions quickly: what could this agent see, and what could it change. A seat answers both from a document. A shared assistant makes you go and find out.

A seat definition we would accept has four parts:

• The job, in one sentence, including what the agent is accountable for finishing.
• Read scope: which systems and which records, expressed as an allow list rather than a list of exclusions.
• Write scope, kept deliberately narrower than read scope, and routed through an approval gate for anything that touches money, clients or staff records.
• Escalation: what the agent does when it needs something outside its scope, which should be a request to a human or another agent, never a workaround.

Read scope and write scope being separate matters more than it sounds. Most of our agents read broadly within their function and write almost nothing directly. We covered how the write side works in our post on AI agent governance and write gates. This post is the read side, which is the half that tends to get skipped because nothing visibly breaks when it is wrong.

How do you scope an AI agent's permissions?

Scope permissions outside the agent, deny by default, and give each agent an identity it cannot assert for itself. The controlling principle is that the agent should never be the component that decides what the agent is allowed to see. If the claim travels with the request, the agent can forge it.

The zero trust literature got here first. NIST Special Publication 800-207, written by Scott Rose and Oliver Borchert of NIST with Stu Mitchell of Stu2Labs and Sean Connelly of DHS, sets the frame: "Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments." Swap network segments for containers and the guidance transfers to agents intact. The resource is what you protect. Where the agent happens to run is not a security boundary.

What that looks like in a build:

• Put the data outside the agent's reach and serve it through a gate, so the agent asks for records rather than opening files.
• Bake the agent's identity into its own access key rather than passing it as a parameter, so an agent cannot claim to be a different one. This is the single change that would have prevented our incident.
• Default to deny and grant by explicit pattern, so a system nobody scoped is unreachable rather than open.
• Keep the permission rules in a file the agent can neither read nor write, owned by the host.
• Log every request with the identity that made it, so an action can be reconstructed later without guesswork.

The same discipline applies whether the agent is built in-house or assembled from a platform. If you are choosing tools, the question to ask a vendor is not whether they support permissions. It is where the permission decision is evaluated, and whether an agent that misbehaves can reach the thing that evaluates it. Our AI agent development team scopes every agent before it is built, because retrofitting isolation onto a running mesh is considerably more expensive than designing it in.

If you want the architecture rather than the summary, the full build is written up in our AI operating system service page, and the deployment itself is documented in the Neogen AI OS case study.

How do you prove an AI workforce's permissions actually hold?

Test them on a schedule, with negative and positive cases, and treat a failure as an outage. Permissions are not a configuration you set once. They drift every time you add an agent, a data source or a skill, and the drift is silent because nothing breaks when an agent can see too much.

We run 110 access-control tests daily across 16 agents and 150 skills, installed 317 times as scoped loadouts, and we expect 110 out of 110. The number matters less than the shape of the suite. Roughly half the tests assert that an agent can reach what it should, and half assert that it is refused what it should not.

That balance came from a bug that would otherwise still be running. A stray comment after a list in the permission file broke the parser, and the parse failure silently resolved to zero permissions for one profile. Every negative test passed, because an agent with no access is refused everything. Only the positive assertion caught it: the agent that was supposed to read its own records could not. A suite made only of "this must be denied" checks would have reported a clean run on a completely broken configuration.

Two habits we would recommend to anyone running agents in production:

• Assert the permission a role is supposed to have, not only the ones it is supposed to lack. A deny-only suite cannot distinguish working from dead.
• Have an adversarial pass on the design, separate from the person who built it. Our container isolation gap was raised by a review, not by monitoring, and our first attempt at restricting host access was incomplete until a second pass found that the restriction still allowed a general-purpose shell.

How should a company start building an AI workforce?

Start with one seat, fully scoped, on a job with a clear finish condition. Resist deploying several agents at once, because the permission problems only appear at the boundaries between agents, and you want to understand one boundary before you create six.

A sequence that has worked for us and for clients:

• Pick a job someone currently does that has a defined input and a checkable output, such as reconciliation, lead routing or reporting.
• Write the seat definition before selecting any tooling. If the authority list is hard to write, the job is not ready to delegate.
• Give the agent read access first and let it produce recommendations for a few weeks, so you can judge its output before it can change anything.
• Add write access one action at a time, behind an approval gate, starting with the lowest-consequence action in the job.
• Add the second agent only once you can state what happens if the first one is compromised.

The unglamorous truth is that most of the work is the scoping, not the model. The agent that reconciles our accounts is not a technically remarkable piece of software. What makes it safe to run is that it cannot see payroll, cannot move money without a gate, and cannot pretend to be the agent that can.

If you are weighing up an AI workforce and want a straight answer on what should and should not be delegated in your business, talk to us and we will map the seats before anyone writes a line of code.

Frequently asked questions

Do we need a separate AI agent for every employee?

No. Seats map to jobs, not to headcount. One agent can serve a whole team if the team shares one authority list, and one person may trigger several agents that each hold different scopes. We run 16 agents for a company with far more people than that, because the agents are organised around functions such as finance, HR and operations rather than around individuals.

What happens when an agent needs data it is not scoped for?

It gets refused, and the refusal is the correct outcome. The agent should then escalate to a human or to an agent that does hold the scope, rather than finding another route. This is worth stating explicitly in the agent's instructions, because a capable model will otherwise try to be helpful and look for a workaround, and the fact that a path exists is not permission to use it.

Can we start with shared access and tighten it later?

You can, but price it honestly. Retrofitting isolation meant rebuilding how every agent runs and re-testing every rule, and until that landed, credentials had been readable across agents for weeks. Deleting exposed data does not undo exposure. Only rotating the credentials does, and that is a much larger job once agents are live and depended on.

Does this work with platforms like n8n and GoHighLevel?

Yes, and the principle is unchanged. Give each automation its own credential rather than a shared admin key, and scope that credential in the target system to the records the workflow actually needs. Most platforms let you create limited-scope tokens; the common mistake is issuing one high-privilege key and reusing it across every workflow because it is quicker to set up.

Who is accountable when an AI agent does something wrong?

The person who owns the seat. Attribution is only possible if each agent acts under its own identity and every action is logged against it, which is the practical argument for per-agent credentials even in a business with no regulatory pressure. If several agents share a login, you can see that something happened but not which agent did it, and accountability becomes a matter of opinion.