Permissions that travel with the person

An AI assistant should own no permissions. It borrows the rights of the person using it, for the duration of the request, and nothing more. The shortcut that replaces it, one shared service account for everyone, eventually hands a language model more access than any single employee has, which is exactly backwards.

Key takeaways

• A shared service account accumulates the union of every user's needs, so the assistant behind it ends up with more access than any individual person.
• Prompt injection is a matter of when, not if: ARGUS, one of the strongest published defences, cuts attack success from 28.8% to 3.8% on its benchmark, which is impressive and still not zero.
• Because no defence reaches zero, the permission model decides what a successful attack is worth, and per-person scope makes that price small.
• Tool lists derived from the user's role make out-of-scope actions invisible rather than forbidden: a tool that is not listed cannot be called.
• Identity, role and scope belong in fields the server fills in; nothing the model writes should decide who is asking.

Why is a shared service account the default failure?

Convenience produces the same architecture in every company: one service account for the assistant, wired once, working for everyone. The account needs to serve the support team, the finance team and management, so its permissions grow into the union of all their needs. The result is a single identity with more access than any employee in the building, standing behind a component that takes instructions in natural language from anyone who can type at it.

Every request then looks the same to the downstream systems. The log says the assistant read a contract; it cannot say for whom, because the identity that reached the database was the assistant's own. Access reviews stop working too: nobody can answer which people would lose reach if a permission were removed from the shared account, so permissions are only ever added.

None of this involves an attacker yet. It is just entropy: shared identities absorb scope, and scope, once absorbed, has no owner who could give it back. The failure is structural, and it is in place before the first malicious prompt arrives.

What does it mean for permissions to travel with the person?

Inversion is the whole idea: the assistant is not a user, it is a proxy. When a person asks their assistant a question, the request that reaches internal systems carries that person's identity, their role and their scope, and the systems answer exactly what they would answer the person directly. The assistant adds convenience, not reach.

Mechanically that means per-person credentials instead of one shared key, so every downstream call is attributable to a human. It means scope is evaluated at request time against the person's current rights, not against a snapshot: a permission revoked at noon is gone from the assistant at noon. And it means offboarding needs no special case, because revoking the person's access revokes their assistant's access in the same motion; there is no separate assistant account to remember and forget.

The attribution alone changes behaviour. A log line that reads "the assistant queried salaries" starts an investigation with no suspect. A log line that reads "the assistant queried salaries for this authenticated person" is an answer, and everyone knows their questions arrive under their own name.

How do roles decide what an assistant can even see?

Filtering the tool list is the cleanest enforcement point, and it is the reason I put role logic in the MCP server I described in what an internal MCP server actually solves. When an assistant connects, the server derives the visible tool list from the authenticated person's role. A tool outside that role is not rejected when called; it is never listed, so the model does not know it exists. Invisible is a stronger property than forbidden: a forbidden action can be requested in a hundred phrasings, an invisible one cannot be requested at all.

The parameters that decide scope get the same treatment. Nothing the model writes should determine who is asking: identity fields are filled server-side from the authenticated session, and a schema whose region or owner parameter is server-filled cannot be talked into someone else's data. The model chooses what to ask for; the server decides, from information the model never touches, whom it is asking as. Prompts remain what they are, requests, and the contract lives where contracts belong, in the code that validates every call.

What do permissions buy when an injection succeeds?

Assume the attack works, because sometimes it will. The research on this is converging: a 2026 survey of 247 papers on agent security finds prompt injection and tool-mediated control-flow hijacking still dominate the field, and judges current defences useful but weakly compositional. The most encouraging result I have seen this year is ARGUS, a defence against context-aware injection, where a malicious instruction hides inside the very evidence the agent must read to decide what to do. On the AgentLure benchmark, ARGUS cuts attack success from 28.8% to 3.8% while keeping 87.5% of clean-task utility.

A drop by a factor of seven is real progress, and 3.8% is still not zero. At production volume, a few percent means a matter of time. So the practical question is not whether an injection will ever land but what it can reach when it does, and permissions are that answer. Under a shared account, a landed injection speaks with the union of everyone's rights. Under per-person scope, it speaks with the rights of one person, on whose behalf every action was logged, in a tool list that hides everything outside their role. Detection tells you how often things go wrong; the permission ceiling decides how expensive wrong ever gets.

What does this look like in practice?

In the internal MCP server I am building, currently in testing, permissions travel exactly this way by design: each colleague authenticates with a personal key, the tool list is derived from their role, identity fields are server-filled, and read-only tools come before anything that writes. None of that required inventing new security machinery; it required refusing the shortcut of a shared account on day one, when the shortcut was tempting and the user count was small.

Open questions remain, stated honestly. Delegation is unsolved in the design: when a manager's assistant prepares something using an analyst's data access, whose permissions apply and how is that recorded. Long-running background tasks are a second gap, because rights valid when a task starts may be revoked before it finishes, and re-checking at every step has a cost I have not measured yet. Those are the next design decisions, and I would rather publish them as questions than pretend the model is complete.

FAQ

Why not one service account with careful prompt instructions?

Prompt instructions are requests to a model, not constraints on it, and the survey cited above finds injection attacks remain the dominant, unsolved threat. A shared account puts the union of everyone's permissions behind those breakable instructions. Per-person scope moves the constraint into infrastructure, where phrasing cannot negotiate with it.

What happens to the assistant when someone leaves the company?

Nothing special, which is the point. Offboarding revokes the person's credentials, and their assistant loses every capability in the same motion, because it never had rights of its own. Under a shared-account design the leaver's reach survives inside the service account, invisibly, until someone remembers to audit it.

Do defences like ARGUS make strict permissions unnecessary?

No, they stack. Detection and provenance decide how often an attack lands, and the residual few percent that ARGUS still leaves shows detection alone is not enough; the permission model decides what a landed attack is worth. Run both, and size the ceiling as if detection will occasionally fail, because it will.

How granular should assistant roles be?

Start from the roles your organisation already has, and map each to a tool list; resist inventing a per-person permission matrix on day one. Coarse roles with server-filled identity fields already bound the damage to one person's scope. Refine where the audit log shows real need, not where the org chart suggests theoretical elegance.

References

• Shihao Weng, Yang Feng, Jinrui Zhang, Xiaofei Xie, Jiongchi Yu, Jia Liu. ARGUS: Defending LLM Agents Against Context-Aware Prompt Injection, 2026. arxiv.org/abs/2605.03378
• Yuchen Ling, Shengcheng Yu, Zhenyu Chen, Chunrong Fang. Toward Secure LLM Agents: Threat Surfaces, Attacks, Defenses, and Evaluation, 2026. arxiv.org/abs/2606.10749