Tenant-Scoped Context and Least-Privilege Tools for Business Agents
Context is a permission boundary#
When an agent handles business work, context is not just information for a better prompt. Context determines which customer, workspace, policy, source, and records are in scope.
That makes context part of the authorization model.
An agent that sees the wrong customer record can produce a perfectly coherent answer that is still a serious operational failure. An agent that sees too much data creates a different problem: the workflow becomes difficult to explain, audit, and constrain.
Start with the tenant, not the prompt#
A safer workflow derives tenant identity from the authenticated server context and then loads the permitted records for that tenant. The prompt can express the task, but it should not be able to select another organization’s data.
The practical sequence is:
- establish the authenticated organization and actor;
- open a tenant-scoped transaction or request context;
- resolve the conversation, customer, or task inside that scope;
- retrieve only the source material allowed for the workflow;
- expose tools filtered by tenant, actor, policy, and action risk.
This is less glamorous than a broad agent demo, but it is what lets an operator reason about whether the agent was allowed to see and do the thing it attempted.
Least privilege applies to tools too#
Tool availability should follow the workflow. A customer-question workflow may need knowledge search and an internal draft tool. It may not need outbound sending, billing mutation, or arbitrary data access.
Use a simple capability table:
| Workflow stage | Example capability | Default posture |
|---|---|---|
| Understand | Read scoped conversation and sources | Allowed when tenant and record scope match |
| Propose | Draft an internal response or action | Allowed with evidence and uncertainty visible |
| Decide | Ask for human authority | Required for policy or customer-impacting risk |
| Commit | Write through governed business tools | Only after policy and idempotency checks |
| Deliver | Send an external effect | Explicitly enabled and separately evidenced |
The smallest useful tool surface is easier to test. It also gives the operator a clearer explanation when the agent says it cannot perform an action.
Context needs evidence, not just retrieval#
Retrieval quality is not only about returning text. The workflow should preserve enough evidence to answer:
- which source was used;
- whether the source was current and in scope;
- whether sources conflict;
- whether the answer should stop and ask for a human;
- how the source influenced the proposed action.
When evidence is missing or conflicting, the correct outcome may be a safe gap or handoff rather than a confident completion.
A practical Atlas evaluation#
Mirai’s Atlas developer overview frames REST and MCP surfaces as sandbox or staged evaluation paths. The first-request guide shows where to begin, while the generated reference remains the contract source.
For a real evaluation, inspect:
- the organization-owned credential and scope;
- the server-filtered tool manifest;
- the knowledge or source lookup response;
- the approval or dry-run boundary where applicable;
- the action history or receipt;
- the failure and retry behavior.
Do not infer production availability from a public code sample. Use the maturity label and the target deployment evidence.
The operator experience is the final test#
Least privilege is working when the operator can answer three questions without reading model internals:
- What did the agent know?
- What was it allowed to do?
- What durable result did the system commit?
If the interface cannot answer those questions, the system may still be useful as a prototype, but it is not yet an operating layer the business can confidently own.
Bring a scoped workflow
Evaluate one real tenant, source, tool, approval, and receipt path before expanding the agent’s authority.
Explore Atlas evaluation