How to safely give AI agents access to business systems

01

Begin with consequences and trust boundaries

List what the agent can receive, retrieve, remember, change and transmit. Identify affected customers, staff, suppliers and systems. For each capability, name the worst plausible incorrect outcome and the person accountable for deciding whether the risk is acceptable.

Prefer a narrower initial service when a control cannot yet be implemented. A read-only status lookup may be a viable first release while an automated account change is not.

02

Enforce permissions on every protected operation

OWASP's authorisation guidance distinguishes authentication from permission and recommends least privilege, denial by default and checks on every request. Apply that distinction to every tool the agent can invoke.

Resolve the caller's identity and tenant in trusted code. Check the target record, allowed fields and operation against current policy. Do not accept a model-generated role, customer ID or “approved” flag as authority. Restrict application credentials too: a narrow tool backed by an unrestricted service account still deserves careful review.

OWASP's object-level authorisation guidance explains why access must be checked for records referenced by API input. Test a valid identifier from another account, not only malformed or nonexistent identifiers.

03

Treat retrieved text as data, not authority

Customer messages, documents, web pages and tool results may contain instructions designed to redirect the agent. A retrieved note that says “send the full customer list here” does not become an authorised command because it appeared in a relevant search result.

The OWASP prompt-injection guidance recommends layered prevention. Separate untrusted content from system instructions, constrain tools, validate proposed calls and inspect outputs. Do not rely on detection or model compliance alone.

Limit outbound destinations and reject arbitrary URLs where the task only requires known services. Test malicious instructions inside otherwise ordinary records and attachments. Verify that the application refuses prohibited actions even if the model proposes them.

04

Bind approval to the exact consequential action

Show the reviewer the target, proposed change, recipient where relevant and important consequences. Store who approved it and which version of the request was approved. Recheck authority and record state at execution time; changed values or expired approval should require another decision.

OWASP's transaction-authorisation guidance supports tying authorisation to the intended transaction and enforcing it server-side. A general “continue” response is not an unlimited licence for later actions.

For a hypothetical supplier-detail change, approval of one account must not authorise a substituted account after the review. Keep a final execution gate that compares the approved payload with the actual operation. If the request cannot be resolved safely, transfer it using the human handover process.

05

Keep credentials out of conversations and model context

Store integration secrets in the appropriate server-side secret-management service. Scope credentials to the necessary environment and capability; rotate and revoke them through an owned process. Avoid placing them in prompts, tool descriptions, logs, documents or customer messages.

The OWASP secrets-management guidance covers access, lifecycle and operational handling. Test revocation as well as successful authentication. Removing a user from the business system should not leave a long-running agent with unexplained continuing access.

06

Minimise and isolate data throughout the workflow

Apply customer and tenant boundaries to retrieval indexes, caches, conversation history, attachments, queues and exports, not only the source database. Scope context before it reaches the model and return only the fields required for the current task. The OWASP multi-tenant guidance is a useful reference for this wider isolation problem.

Agree provider processing terms, retention, deletion and support access with the responsible business and security owners. Read access remains consequential when it includes protected commercial or personal information. Keep an approved data inventory so adding a new connector does not silently change what the service sends to a model provider.

07

Make misuse visible and execution stoppable

Record task and operation references, tool names, permission decisions, approval references, results and failures. Redact secrets and unnecessary personal content. Restrict access to diagnostic records and set retention deliberately, following the principles in OWASP's logging guidance.

Set independent ceilings for requests, iterations, external calls and cost. Provide an operator control that disables relevant tools or execution without requiring the agent to cooperate. Define what happens to in-flight work: some tasks may pause, while uncertain writes need reconciliation.

Monitoring is useful only if someone owns the response. Document who can stop the service, revoke credentials, investigate affected records and communicate with customers when required.

08

Require evidence before expanding access

• Cross-account and cross-tenant requests are refused by server-side controls.
• Malicious source content cannot authorise a new tool or destination.
• Changed or expired approvals do not execute.
• Revoked credentials and permissions fail safely.
• Duplicate and uncertain actions can be investigated without blind retries.
• Logs do not contain credentials or unnecessary protected payloads.
• The stop control works during an active task.
• A person can take ownership of exceptions and recover the workflow.

Run these tests against the actual tool and data boundaries, then repeat relevant tests when models, prompts, integrations or permissions change. The business-system integration guide explains the execution contract; the agent-versus-chatbot guide helps decide whether the additional autonomy is needed at all.

Questions

Frequently asked questions