Adding an AI call to a business system changes more than the prompt. The request still travels through identities, networks, secrets, data stores, logs and recovery procedures. If those boundaries are unclear, a carefully written system instruction cannot carry the whole security load.
This is a practical infrastructure checklist for an AI workflow that reads business information and can call a limited set of tools. The architecture below is hypothetical. It is not a description of a client network, and the checklist is not a compliance certification.
Start with the complete request path
Draw the path before choosing controls:
- Who starts the request, and what identity reaches the application?
- Which service prepares the prompt and selects context?
- What model endpoint receives the request?
- Which tools can the model call?
- What system receives the result, and what can it change?
- Where do failures, approvals and audit records go?
A useful map names the identity and trust boundary at every hop. “The agent” is too broad. A browser user, web application, retrieval service, model endpoint and ticketing connector may all have different permissions. Treating them as one actor makes review difficult and often hides an unnecessary privilege.
Keep model safeguards separate from infrastructure controls
Prompt filtering, output validation and tool-use rules still matter. OWASP’s 2025 guidance identifies prompt injection and excessive agency as separate risks. It describes excessive agency in terms of excessive functionality, permissions or autonomy, including extensions that can do more than the intended task or identities that can write when they only need to read.
That distinction gives the review two tracks:
- Model-facing controls: define trusted instructions, treat retrieved text as data, validate structured outputs and test direct and indirect prompt injection.
- Service controls: use separate identities, restrict network paths, limit credentials, validate tool arguments and require approval for high-impact actions.
Neither track replaces the other. A model can follow its instructions and still be connected to a service account that has too much access. A tightly scoped account can still be exposed to unsafe model output if the application does not validate it.
Give the agent a narrow operating envelope
Begin with the smallest useful tool set. If the workflow needs to read a knowledge store and prepare a draft, do not give it a general database connection, shell access or a broad file share. If it needs to update one queue, expose an operation that updates one queue item with validated fields. Avoid open-ended commands where a specific function will do.
Separate read and change identities where possible. Use a read-only identity for retrieval, a constrained write identity for a narrowly defined update, and a human approval step for actions that delete records, contact an outside party, move money or change access. The approval should be part of the workflow, not a sentence hidden in a prompt.
Place limits around data egress as well. Define which fields may leave the system, which destinations are allowed, and what the application must redact before sending context to a model or connector. Network allowlists, private endpoints or equivalent controls can reduce exposure, but they do not decide whether a piece of business data belongs in the request. The application still needs a data classification and minimization rule.
Use secrets as an operational dependency
Do not put long-lived API keys in prompts, source files or browser-visible configuration. Store credentials in the approved secret system, give each connector its own identity where practical, and record who owns rotation and revocation.
A useful test is simple: if a connector is compromised, can the team revoke that one credential without taking down unrelated workflows? If the answer is no, the boundary is too wide. Also test expiry, failed rotation, a disabled account and a provider outage. Recovery plans that depend on the same broken connector are not recovery plans.
Log enough to investigate, not everything by default
Security logs should show the request ID, actor, service identity, tool selected, authorization result, destination, outcome and timing. They should help an operator reconstruct what happened without copying every sensitive prompt and document into a permanent log.
Decide in advance which content is retained, which fields are redacted, who can inspect it, and how long it remains available. Log a reference to a controlled record when the full payload is not needed. Test the logs with synthetic data and confirm that an operator can trace a failed or suspicious action from the user request to the destination system.
Rehearse the failure paths
Before production use, run a short operational exercise with a hypothetical workflow:
- Inject untrusted instructions into a retrieved document and confirm that the application treats them as data.
- Attempt a tool call with an invalid argument and confirm that validation blocks it.
- Revoke the connector credential and confirm that the workflow stops safely.
- Disable the model endpoint or network route and confirm that work moves to a visible review queue.
- Restore the dependency and verify that retries do not duplicate an external action.
- Roll back the last workflow change and confirm who owns the decision.
Record the expected result, observed result, evidence and owner for each test. The goal is not to prove that a system can never fail. It is to make failure bounded, visible and recoverable.
A practical review question
Ask this for every connection: “If the model is wrong, what is the most damaging action this path permits, and which independent control stops it?” If the answer is “the prompt tells it not to,” the design needs another boundary.
Current public guidance can help structure the review. OWASP’s Top 10 for LLM Applications covers model application risks, Microsoft’s Azure OpenAI security baseline covers service and platform controls, and NIST’s AI Risk Management Framework provides a broader risk-management vocabulary. Use them as review inputs, not as proof that a particular architecture is safe.
If AI is being connected to business systems, we can help review the infrastructure and access boundaries around it through Cloud & Integration.