Connecting an AI capability to a tool is not the same as designing a safe product integration. The important work happens before execution: defining the objective, deciding which information the capability may consult, limiting the actions it may take and establishing how a person or system will validate the result. Least privilege turns those decisions into a clear product boundary. Instead of granting broad access and relying on a prompt to restrain behaviour, the integration exposes only what one defined role needs.
Define one role before granting access
Start with a sentence that describes the capability's job and its intended result. A capability that organises authorised information, one that prepares a proposal and one that performs a specific software action have different permission needs. If the role cannot be described precisely, its access cannot be scoped precisely. Broad labels such as assistant or agent hide the distinction between reading, interpreting, proposing and changing something.
Viotus's public design boundary for Calculator and Valuator makes that structure concrete. Calculations, rules and structured data remain in controlled systems; an intelligent layer may organise information, explain a scenario or suggest how to explore a question, but it must distinguish calculated output, generated content and professional judgement. That is a specific permission decision: the AI may help a person navigate or interpret the result, but it does not inherit the financial engine's authority or present generation as calculation. The accompanying evidence must show where data originated, which operation was performed and which part still requires human interpretation.
Separate information access from action rights
Reading and acting are different powers. An integration may need to consult a small set of records without being able to edit them. It may need to prepare a change without applying it, or invoke one narrow operation without browsing the rest of a service. Treat each permission as a specific capability rather than granting general access to an account, database or application.
List the minimum inputs required for the task and exclude everything else. Sensitive content should be removed, reduced or protected before it reaches the capability. Then list the exact operations the tool exposes, including their allowed targets and parameters. A connection that offers many unused actions increases the consequences of ambiguity, manipulation or a simple mistake without improving the intended result.
Make the boundary enforceable outside the prompt
Instructions explain the role, but the surrounding system should enforce it. A read-only task should receive read-only credentials or an adapter that cannot write. A tool intended for one record should reject other targets. A proposal workflow should stop before application and pass its output to a separate review step. The model should never be the only component deciding whether its own request is authorised.
Use structured inputs and outputs where the task allows them. Required fields, constrained values and narrow tool contracts reduce uncertainty about what the capability requested and what the tool returned. Validation can then check the result against the objective and the permission set. Free-form language may help a person understand an outcome, but it should not silently expand the operations available to the capability.
Test ordinary, ambiguous and hostile requests
A permission design is incomplete until it is exercised at its edges. Test a normal request, missing information, conflicting instructions and a request that requires an unavailable action. Add attempts to obtain unrelated information, change role, bypass review or use a permitted tool against an unpermitted target. The safe outcome may be a bounded refusal or a request for clarification rather than a generated answer.
Check the whole path, not only the wording of the response. Did the capability receive data it did not need? Could it call another operation even if it chose not to? Did the adapter reject an invalid target? Did the workflow stop at the required review point? A polite refusal is not proof of least privilege when the underlying connection still carries broad authority.
Validate and record every meaningful result
A result should remain connected to the objective, authorised inputs and tool operations that produced it. Preserve enough information to distinguish retrieved facts, deterministic operations and generated interpretation. The record should make review possible without turning logs into unnecessary collections of personal or sensitive information. Traceability and data minimisation must be designed together.
Validation should match impact. A low-risk suggestion may need a clear source trail and human acceptance. A proposed change may need deterministic checks and a separate approval identity. An operation with important consequences may not belong in an autonomous path at all. Least privilege limits what can happen; validation determines whether the permitted result is acceptable; the record explains what happened and why.
Review permissions as the role changes
Permissions should follow the current task, not accumulate with every new feature. When an integration gains a tool, changes provider or begins handling a new class of information, reassess the objective, inputs, operations, validation and failure path. Remove access that is no longer required. A more capable model does not by itself justify a wider boundary.
A practical review can ask five questions: Is the role still singular and clear? Is every available data field necessary? Is every tool operation required? Can the system enforce the boundary without trusting generated text? Can a reviewer reconstruct the result from a proportionate record? If any answer is uncertain, keep the capability closed until the design is narrower. Useful AI integration begins not with everything a model could do, but with the smallest verifiable role the product actually needs.