Taxonomy-scoped authorization for AI agents: when roles aren't enough

Everyone had the right role. The AI crossed the wrong portfolio.

An investment manager runs one application for research, portfolio review and task creation. Dozens of people share the role Portfolio Analyst, but they don't cover the same funds. One analyst is assigned to Public Credit, North America, Fund Alpha. Another team uses the same role for Private Markets, Energy, Fund Delta. The screens show the first analyst only Fund Alpha, and the main database queries filter correctly.

The analyst asks the AI assistant: "Which holdings need action before month-end?" The retrieval service filters by tenant and role, but not by portfolio. A confidential valuation memo from Fund Delta lands in the candidate set. It isn't quoted in the answer, but it changes the ranking, and the model flags an issuer because of an acquisition the analyst isn't cleared to know about.

The model then proposes a risk-review task. The tool is visible because Portfolio Analysts may create risk-review tasks. The runtime checks the role, not the portfolio of the target record. A task appears inside Fund Delta.

Every component can defend itself. The user was in the right tenant, the role was valid, the tool was permitted, and the API accepted an authenticated service credential. The failure was a missing relationship between role, business domain, purpose and the state of the work.

Is RBAC enough for AI agents?

Not on its own. Roles describe what kind of work someone may do; they don't describe which portfolio, product, region or legal entity that work applies to, and agents cross those lines constantly.

Role-based access control is still one of the best tools enterprises have. It ties permissions to job functions instead of individuals, and the NIST model supports hierarchies and constraints. Nothing here argues roles are obsolete.

The problem is that one role spans many business domains. A claims reviewer may handle only commercial auto in two states. A legal approver may sign only for one region and legal entity. A support engineer may see evidence for one product line. Encoding each combination as its own role ("Portfolio Analyst, Fund Alpha, Europe, Temporary") produces role explosion. The role catalog becomes a fragile, out-of-date copy of the org chart.

The fix is to keep roles stable and ask the other questions separately:

Roles answer what. Scope answers where.

An authorization taxonomy is a governed set of business concepts and their relationships: organization, product, geography, portfolio, document class, data classification, process stage. A record can sit in several at once. A contract can belong to a legal entity, a region and a restricted document class simultaneously.

Free-text tags don't cut it. "EMEA" in one system and "Europe" in another may or may not be the same thing. A safe taxonomy needs stable concept IDs, a declared scheme and version, an owner, lifecycle rules and a record of where each label came from. Display names can change without changing the concept; concepts can be retired or moved while the label still looks familiar. Standards such as W3C SKOS give you a neutral way to model concepts and broader/narrower relationships, but SKOS doesn't decide access. Policy does.

Effective permission is an intersection, not a lookup. Permit only when the role allows the action, the subject's scope covers the resource's scope, tenant and legal entity match, the purpose is allowed, the current state satisfies policy, and no deny, expiry or separation-of-duty rule blocks it.

Does a parent grant include its children?

Only if your policy says so explicitly. Hierarchies simplify policy when inheritance direction, depth, exceptions and multi-label rules are declared, and quietly expose data when they're assumed.

Most taxonomy leaks come from informal assumptions about the tree:

The last row matters most. Missing or ambiguous scope should produce a typed outcome (out of scope, unclassified, stale, needs review), never a silent default to broad access.

Authorization is only as good as its attributes

A perfectly written policy still gives the wrong answer when its inputs are wrong. NIST guidance on attribute-based access makes the point directly: confidence in a decision depends on how attributes are defined, kept accurate, secured and managed.

In practice, scope goes wrong when:

• a user keeps an old portfolio assignment after a reorganization;
• a document is reclassified, but its chunks, embeddings, summaries and cache entries keep the old label;
• two systems use the same label for different concepts;
• a data mapping drops the legal-entity or document-class field;
• a feature is computed from records broader than the workflow consuming it;
• a taxonomy changes while long-running work keeps the old interpretation.

Every scope-bearing attribute needs an authoritative source, a version, a freshness rule and provenance. Scope strings supplied by the caller, including by the agent, shouldn't be trusted at all.

Where does scope leak in an AI application?

Scope leaks wherever meaning is selected or created: retrieval and ranking, context assembly, model memory and caches, agent and tool calls, human approvals and long waits. Each needs its own check.

Retrieval: filter before you rank

If candidate generation, top-k budgets or reranking run across branches the user can't see, restricted material changes which allowed material survives, even when the final context contains only permitted text. That's exactly what happened with the Fund Delta memo. Apply scope before the candidate set is formed, label every chunk with its source scope, and push reclassification through to derived indexes. The same logic applies across tenants; see tenant isolation for agents and RAG.

Context, models and memory inherit scope

A model can cross a boundary without copying a sentence. It can summarize, infer, rank or propose an action based on restricted evidence. So a generated answer isn't scope-free just because it's new.

Agents and tools can't widen scope

A sub-agent or reusable workflow should receive scope equal to or narrower than its parent's, carried explicitly, and should check it again at its own retrieval and tool calls. Role-only tool visibility is the most common gap. An authenticated service credential proves the software may call the API. It doesn't prove this work may act on this record in this branch. This is the object-level authorization failure OWASP ranks first for APIs. See AI agent identity and delegated authority for how that authority should narrow at each hop.

Approvals have a scope too

A reviewer role doesn't confer authority over every proposal of that type. A legal approver for Germany shouldn't approve a French contract because it reached the same queue. The approval should record the reviewer's scope, the proposal's labels and the exact action approved, and be re-evaluated if the proposal moves across a boundary after review.

Scope changes while work waits

Long-running work adds time, which static role checks miss. While a case waits for a document or a signature, the user can move to another portfolio, the record can be reclassified, a concept can be split or merged, policy can change how inheritance works, or an approval can expire.

So record the taxonomy version and the assignments that actually resolved when the work started. Before resuming or committing, recheck anything whose legitimacy depends on the present. Then decide: continue, refresh attributes without changing what was authorized, narrow the context or tools, ask for reapproval, migrate to the new taxonomy version, or stop.

Make scope visible and testable

Scope is a relational question: which subject scope, resource labels, action, purpose and state meet at this point? That's easier to review when it's visible. Reviewers should be able to see concept IDs and labels, inheritance and deny rules, subject grants and expiry, where each check is enforced, and an explanation of why a simulated request is permitted or denied. Queries should show whether the scope filter runs before ranking or after. Mappings should flag fields that are dropped.

Then test the negative cases, not just the happy path. NIST's work on access-control verification stresses testing the policy model itself:

The strongest test is a single rule: no unauthorized branch may disclose information, influence ranking or reasoning, authorize a decision, enable a tool, receive an output or cause an effect for this piece of work.

Common anti-patterns

Ten rules for taxonomy-scoped authorization

1. Use roles for job function and scope for business domain.
2. Give every concept a stable ID, scheme, version, owner and source.
3. Declare inheritance, multi-label, deny and missing-scope behavior.
4. Derive scope from authoritative sources; never trust caller-supplied scope.
5. Label every derived artifact (chunk, summary, feature, cache, output) with its source scope.
6. Apply scope before retrieval budgets, ranking, model context and tool exposure.
7. Pass equal or narrower scope to every sub-agent, workflow and approval.
8. Version scope rules, and recheck them when work resumes or commits.
9. Make scope checks visible to reviewers, and flag mappings that drop scope.
10. Test sibling, parent-child, multi-label, reclassification and service-credential cases continuously.

The result: role simplicity without role blindness

Roles stay valuable as a stable vocabulary for job function. AI doesn't change that. It exposes the limit of treating role membership as the whole answer. Agents select evidence, write summaries, keep memory, call tools, wait for people and change records, and each of those steps can cross a portfolio, product, region or data class while the user stays in the right tenant with the right role.

Taxonomy-scoped authorization makes the domain boundary explicit and checks it every time it matters. A role decides the kind of work. Scope decides where that authority applies, and the record shows which branch of the business shaped every outcome.