Clear, source-led guidance for accountable business AI.
A practical method to bound an AI assistant’s data, tools, permissions, actions, approvals, refusals, evidence and operating controls.
ModelFold Editorial Team9 min read
A bounded AI assistant is an executable business service contract, not a system prompt containing polite prohibitions. Telling a model not to send a message is immaterial if the surrounding service still gives it a sending tool and a credential with broad access. The dependable boundary sits in eligible data, acting identities, narrow operations, downstream permissions, approvals, stop conditions and evidence records. Designing these controls capability by capability prevents an ordinary request from inheriting unrelated information or authority.
The design rules that matter
The team should begin with a one-sentence service charter and explicit non-goals. A useful form is: For eligible users, the assistant may perform an allowed task family using approved information to produce a permitted outcome, but it may not make named consequential decisions. Record the intended users, deployment setting, supported work, knowledge limits, human oversight and risk owner before any tool is connected. These elements reflect NIST AI RMF outcomes, although the compact charter is our practical editorial synthesis rather than a NIST requirement.
Next, replace elastic verbs such as “help” or “manage” with operations that a user can recognise and a control owner can test. Search, summarise, recommend, draft, update, send, delete and approve are not interchangeable: each needs different information, permissions and evidence. OWASP’s minimum-function guidance supports choosing a narrow operation over an open-ended tool. Start with the smallest operation that delivers useful work, while keeping unrelated verbs absent from the service.
Each capability needs an information envelope that defines eligible data and trust boundaries, not just the number of tokens a model can hold. Specify approved systems, record types, classifications, object filters, applicable dates, freshness expectations and the user entitlements that must still be honoured. Name prohibited data as well. If required evidence is inaccessible, missing or stale, the assistant should qualify the answer, request what is missing or refuse; a larger context window creates neither authority nor truth.
Retrieved documents, attachments, external messages and API responses must remain untrusted content rather than quietly becoming service instructions, as OWASP advises. Define session history separately from persistent memory: state what may be carried within a session, what may persist, how users and sessions remain isolated, what validation occurs before storage, and how expiry and deletion work. Service owners should set size and retention limits from real operational, privacy and records needs instead of adopting a universal threshold.
Authentication, authorisation and approval must remain separate decisions enforced around the model. Authentication establishes who or what is present: a user, client, agent or workload. Authorisation determines whether that identity may perform a particular operation on a protected resource. Approval accepts one inspectable proposed action. The Model Context Protocol specification illustrates this separation for protected MCP integrations through distinct client, resource-server and authorisation-server roles, but it is not a universal architecture for every tool.
Choose explicitly whether a tool acts with delegated user authority or a controlled workload identity; never let it silently inherit a privileged operator’s account. Expose validated operations such as reading an eligible case or creating a draft, not a broad mailbox, database, browser or shell. The gateway and downstream service must constrain verbs, resources, fields, destinations, credential duration and token audience. OWASP and NCSC guidance supports minimum permission, complete mediation, secure defaults and external fail-safes. A prompt remains guidance to a model, not an authorisation control.
A conversation may be continuous, but its authority should be divided into small, independently enforced capabilities.
Every capability needs an explicit action ceiling, with stronger independent controls as it approaches an external state change. The following ladder is practical editorial synthesis supported by OWASP and NCSC control principles, not a tiering system prescribed by either body. It separates an answer from a proposal, a draft from a send, and a reversible update from a destructive change. A shared conversational interface must not blur these materially different levels of authority.
For a consequential action, show the actor an exact preview and bind approval to the actor, tool, target, normalised parameters, time and expiry before execution. If the recipient, content or other material parameter changes, obtain fresh validation. Approval never supplies missing authorisation, broadens standing permission or turns a prohibited decision into an allowed one. Payments, access grants, destructive operations, production changes, high-stakes professional judgements and material external commitments require deterministic policy controls and appropriately qualified, accountable human authority.
Refusal, safe partial help, human handoff and security escalation should be explicit service outcomes with genuine stop conditions. NIST’s framework includes safe failure beyond documented knowledge limits, while OWASP describes abuse cases such as approval bypass, privilege escalation, data exfiltration, memory poisoning and recursive tool use. A boundary response should say plainly what cannot proceed without revealing sensitive policy detail. It must never claim that a source check, approval, tool call or write succeeded when it did not.
Offer only the safe portion, perhaps a draft, a checklist or a request for missing information. Package the original goal, relevant non-sensitive context, attempted capability, reason, available or missing evidence, proposed next step and trace identifier for the responsible destination. Keep routine user handoff, business approval and security incident escalation distinct, because their owners and urgency differ. NCSC recommends incident response, escalation and remediation scenarios backed by trained responders and useful audit logs. Pending execution stays stopped, and a changed action requires fresh validation.
Teams should complete one capability-design canvas row for every user-visible operation and connect it to enforceable controls, evidence, tests, metrics and accountable ownership. Record the eligible actor, authentication, information envelope, session and memory rules, narrow tool operation, acting identity, resource scope, action ceiling, approval, operating limits, refusal, evidence record, evaluation scenarios and owner. This canvas is editorial synthesis grounded in the cited guidance; it is useful only when each field maps to something implemented and observable.
Consider an internal support assistant used by account-service staff. Finding a case, drafting a reply and sending an approved message can share one conversation while retaining separate grants and outcomes. OWASP’s minimum-function and minimum-permission guidance supports that separation. Evidence should reconstruct the capability, policy, source and tool classes, authorisation result, approval identifier, outcome and relevant versions without indiscriminately storing message contents or secrets. NIST governance outcomes also support clear roles, monitoring and periodic review.
| Capability | Information and tool boundary | Action ceiling and approval | Evidence, tests, metrics and owner |
|---|---|---|---|
| Find and summarise an eligible case | Delegated read access to cases already visible to the staff member; exclude unrelated accounts and hidden notes. | Answer or summarise only; no write or send operation. | Record source and denial classes. Test cross-account, hidden-note, stale-evidence and unsupported-answer cases; service owner investigates exceptions. |
| Create a reply draft | Eligible case data plus approved knowledge and response policy; write only to a non-final workspace. | Draft only; unsupported commitments require a qualified reviewer. | Record sources, policy version, draft and reviewer outcome. Test missing support, sensitive data, unauthorised promises and adversarial retrieved instructions. |
| Send an approved reply | Separate narrow send operation, authorised customer channel and recipient; validate the approved content reference. | Consequential action requiring valid authorisation, parameter-bound approval and duplicate prevention. | Record sender, recipient, approval and result. Test changed parameters, expired approval, missing authority, retries and outages; messaging owner handles execution. |
Release requires evidence that permitted service and expected denials both work under deployment-like conditions. NIST calls for representative testing, safe failure, production monitoring and regular safety and security evaluation; NCSC recommends pre-release security evaluation and communication of known limitations. Test successful tasks alongside cross-account access, unauthorised tools, stale or poisoned context, prohibited data, approval bypass, changed parameters, duplicate retries, dependency failure, exfiltration attempts and runaway chains. A passing test set is evidence for a defined version and context, not permanent assurance.
Reopen affected tests and release evidence after material changes to models, prompts, retrieval, memory, tools, permissions, policies, data, providers or operating context. NCSC notes that changes to data, models and prompts can alter behaviour and recommends monitoring for sudden or gradual security-relevant change while respecting privacy requirements. Begin with the smallest useful capability, release it only when allowed and denied outcomes are observable, and expand authority through reviewed changes. Involve security, identity, privacy, records, risk and service owners wherever the capability touches sensitive data, privileged access, external commitments or incident response.
A bounded AI assistant is a business service whose tasks, information, identities, tools, actions, evidence, refusals and owners are explicitly limited. Those limits are enforced by the surrounding systems and operating process, not merely described in the model’s prompt.
Create one row for each user-visible capability rather than one row for the whole assistant. Record the eligible actor, data scope, tool operation, resource permission, action ceiling, approval, operational limits, logs, tests, metrics and accountable owner for every row.
Define eligible sources, records, fields, user entitlements, object filters, freshness and trust classes. Set separate rules for session history and persistent memory, including validation, isolation, expiry, size, deletion and prohibited data; choose the actual limits for the service instead of using universal defaults.
No. Approval accepts a particular proposed action, but it cannot replace downstream authorisation, correct excessive standing permission or allow a prohibited decision. The execution service must still validate the actor, operation, resource and approved parameters.
It should refuse or stop when the task or data is out of scope, authority is missing, approval is required, evidence is stale, specialist judgement is necessary, a dependency is unavailable, an operating limit is reached or a security signal appears. It may offer safe partial help, then route a structured handoff to the appropriate service, business or security owner.
This article was researched using the following sources:
We report on how AI actually lands inside a business. Our work starts from named sources, separates what we found from what we think, and uses AI assistance for research and drafting under documented editorial controls. We are not a substitute for individual expert review.
Build a source-grounded AI drafting workflow that keeps evidence, prose, review decisions and consequential edits traceable through approval.
A practical guide to designing reproducible AI evaluation scenarios, valid grading rules and protected release evidence for a bounded business workflow.
Build a compact AI-use inventory, rate exposure across four explainable dimensions, and route every use to proportionate review as its context changes.
