AI applications increasingly have access to tools and data. A model can retrieve documents, query databases, make changes in external services, and trigger workflows. Those capabilities require the same authorization discipline as any other software component. A request expressed in natural language does not change that requirement.
A prompt is not an access control
Instructions to the model can explain the intended behavior of an application. They cannot replace access control enforced by the systems that hold data or perform actions. If a user is not permitted to access a document, the application should not retrieve the document and then rely on the model to avoid disclosing it. The unauthorized retrieval should be rejected before the content reaches the model.
Enforce permissions where actions occur
An AI application needs a reliable way to identify the user, determine which actions are allowed, and constrain each tool call. That generally means checking authorization at a service boundary, not merely in a chat message. Permissions should be scoped to the task and the user. Tokens should have the minimum practical privileges and should be revocable.
Separate instructions, data, and authority
Retrieved pages, files, emails, and other outside content should be treated as data, not as instructions that can grant new privileges. An attacker may place text in a document that attempts to redirect the assistant. If the application accepts that text as authoritative, it can cross a trust boundary. Keeping tool permissions independent of model-generated text reduces the consequences of this class of failure.
Test the negative cases
A useful evaluation does not stop at confirming that permitted requests work. It also checks that prohibited requests fail, that credentials cannot be reused beyond their scope, and that error paths do not disclose restricted data. Tests should cover the way the application behaves when the model produces an unexpected tool argument or when retrieved content contains conflicting instructions.
Document what the system can do
A user or administrator should be able to determine which services are connected, what permissions have been granted, what actions can change state, and how access can be revoked. Where higher-risk operations are involved, approvals and reliable activity records can provide additional safeguards. The model is one component of a broader system; the security design must account for the system as a whole.