Direct answer: secure the agent as a semi-autonomous system
The best practice is to treat agentic AI as a semi-autonomous system with a named owner, a constrained identity, a bounded task, and an auditable control plane, rather than as a larger chatbot. An agent can choose tools, retrieve enterprise content, alter records, and send messages, so a single prompt can create a chain of actions that a normal application call would not. On 10 September 2026, a defensible design combines identity controls, least privilege, retrieval authorization, tool boundaries, human approval, and continuous monitoring across the model, orchestration layer, data sources, and business systems.
Also worth reading: What are enterprise data governance best practices for B2B data un-siloing and secure knowledge exchange in 2026? · What are the definitive agent policy enforcement best practices for enterprise AI systems? · What are the enterprise RAG security best practices for 2026, and how should CISOs design, govern, and audit them?
The strongest baseline is a zero-trust architecture: every request is authenticated, every tool call is authorized against the user’s effective permissions, and every sensitive action is logged with its source context. Access should be denied by default, secrets should be rotated after a compromise, and high-impact actions should require a second factor or human approval. The exact threshold is a risk decision, but a useful starting point is approval for any external transfer above 1 MB, any change to permissions, any payment, and any deletion or publication action. No single guardrail is enough; the control must survive model drift, a malicious document, and a compromised integration.
Why agentic AI changes the security problem
Agentic AI differs from a narrow chatbot because it can pursue a goal over multiple steps, select tools, and act without waiting for a user to specify each operation. That autonomy creates value in workflow automation, but it also moves the trust boundary: the model is no longer only interpreting language, it is deciding which system to call and what parameter to send. A secure deployment therefore needs controls at the planning stage, the retrieval stage, the tool stage, and the execution stage. A policy that only filters the final answer leaves the most dangerous part of the workflow exposed.
The main failure modes are indirect prompt injection, excessive tool access, unsafe data retrieval, credential exposure, and unreviewed side effects. For example, a document can contain an instruction that competes with the user’s request, while a connected email or ticketing tool may make the instruction actionable. A model can also infer a plausible next step that is outside the business process, especially when the goal is vague. The practical response is not to ban agents, but to define a narrow authority envelope and make every expansion of that envelope visible to a person or a policy engine.
Establish identity, authorization, and data boundaries
Start with an explicit agent identity and a service account that has only the permissions needed for its assigned workflow. Do not give the agent a broad administrator token because it is convenient during a pilot; use short-lived credentials, separate production and test identities, and require a fresh authorization decision for each sensitive tool call. A useful design is a three-layer identity model: the human who initiated the task, the agent’s service identity, and the target system’s resource owner. The target system should receive the human’s effective authorization, not merely a statement that an agent is trusted.
Retrieval authorization is just as important as model authorization. Connectors should filter documents before they enter the agent context, and the filter should use the same access rules as the source system, including row-level or field-level restrictions where appropriate. A vector index can improve recall, but a vector similarity score is not an authorization decision; a semantically close document from another department is still unauthorized. Use tenant isolation, encrypted storage, scoped API keys, and separate indexes for different trust domains. Keep a record of which source, document, and permission decision contributed to each action so an incident can be reconstructed.
Build secure tool and execution controls
Tool access should be allowlisted, typed, and limited to the smallest set of operations that the workflow needs. Prefer a read-only connector for discovery, then a separate write connector with a narrow schema, rather than exposing a general-purpose API or shell. Every tool should validate inputs, reject ambiguous commands, enforce rate limits, and return a machine-readable result that the orchestrator can inspect. For high-risk operations, require a two-person review, a time-bounded approval token, or a deterministic policy check before execution. A model’s confidence score should inform routing, but it should not be the only gate for a destructive or financial action.
Use a sandbox for code generation, untrusted file parsing, and experimental tools, with no direct route to the production network. Egress should be restricted to approved destinations, and downloads should be scanned for malicious content before they can influence a workflow. Maintain a kill switch that can revoke the agent’s credentials, pause all tool calls, and preserve the last 30 to 90 days of decision logs, depending on retention requirements. Run adversarial tests at least monthly for critical workflows and after every major model, connector, or prompt change. Security reviews should cover both successful task completion and the agent’s behavior when instructions conflict.
Compare practical security patterns
| Security pattern | Best fit | Main benefit | Main limitation |
|---|---|---|---|
| Read-only agent | Research, summarization, triage | Low side-effect risk and simple review | Cannot complete a workflow without a handoff |
| Human-in-the-loop agent | Approvals, customer responses, regulated actions | A person verifies intent and outcome | Adds latency and can create approval fatigue |
| Fully autonomous agent | Repetitive, low-risk internal tasks | Fast throughput and fewer manual steps | Needs strong monitoring, narrow scope, and rollback |
| Central policy gateway | Many agents and shared systems | Consistent authorization and audit evidence | Adds integration work and a possible availability dependency |
| Local or private model | Sensitive prompts and strict residency needs | Reduces exposure to third-party inference paths | Does not remove prompt, tool, or data-access risk |
Put monitoring, incident response, and governance into daily operation
Monitoring should capture the initiating user, model and version, retrieved source identifiers, tool name, input and output schema, authorization result, approver, and final outcome. Avoid logging raw secrets or unnecessary personal data, but retain enough context to distinguish a benign retrieval from an attempted data exfiltration. Set alerts for unusual tool combinations, repeated authorization failures, a sudden increase in external calls, or a single agent accessing more than 100 previously unseen documents in a short window. The last number is a starting threshold, not a universal rule; tune it against normal workflow volume and false-positive rates.
Governance needs a named owner for each agent, a documented purpose, a data classification, an approved model list, and a renewal date. Review access quarterly, rotate credentials at least every 90 days, and re-test after any material change to a model, connector, prompt, or business process. Maintain an incident playbook that can disable the agent, revoke its tokens, isolate affected connectors, preserve logs, and notify the relevant security and privacy teams. The NSA, ASD’s ACSC, and partners released guidance on agentic AI systems in 2025, while NIST’s AI center sought input on agentic security and best practices in 2025; use those publications as design references, then map their recommendations to your own risk register and control evidence.
Avoid these common mistakes
The most common mistake is treating prompt filtering as the security boundary. Prompt filters can reduce obvious abuse, but they do not reliably stop indirect instructions embedded in retrieved content, and they cannot repair an over-privileged connector. A second mistake is giving every agent the same broad credentials so that a proof of concept can move quickly. That shortcut turns one compromised agent into a broad data-access path and makes it difficult to explain who authorized a particular action. Use a test identity with synthetic data, then grant production access only after the workflow and its failure modes are understood.
Another frequent error is assuming that a private cloud, an open-source model, or a proprietary model automatically solves the problem. Deployment location changes the exposure of prompts and outputs, but tool permissions, retrieval policy, and execution controls remain necessary in every environment. Teams also under-estimate approval fatigue: if every routine action requires a person, users will bypass the process or widen the agent’s permissions. Set a clear risk threshold, automate low-risk checks, and reserve human review for actions with irreversible, financial, legal, or external consequences. Finally, do not measure success only by task completion; track denied requests, near misses, source contamination, and recovery time as security outcomes.
When to act and what it costs
Act before an agent can read production data or call a write-capable system, not after the first pilot demonstrates a useful result. A useful sequence is a two-week threat model and data inventory, two to four weeks of identity and connector controls, and another two to four weeks of red-team testing and approval tuning for a medium-risk workflow. Move faster for agents that handle customer data, credentials, financial transactions, or external communications, and use a read-only pilot when the business case is still uncertain. Reassess the design whenever the agent gains a new tool, model, data source, or autonomous decision.
Costs vary widely because the agent framework, model usage, connectors, logging volume, and review workload differ by organization. A small internal pilot may cost a few hundred to a few thousand dollars per month in model and infrastructure charges, while an enterprise deployment with private inference, high-volume retrieval, SIEM integration, and 24/7 monitoring can reach tens or hundreds of thousands of dollars per year. The largest recurring cost is often not token usage; it is connector maintenance, access reviews, test data, and human approval time. A practical budget should include at least 20% of the initial build cost per year for control tuning, model changes, and incident exercises. Secure knowledge exchange platforms can reduce duplicate connectors and centralize policy evidence, but they do not replace the need for source-system authorization and accountable ownership.
The operating model that holds up
A mature program combines technical controls with a small number of operating rules. Assign one accountable owner, define the agent’s permitted outcomes in plain language, and make the authority envelope visible in the user interface and audit trail. Start with read-only access, add one low-risk write action, and only then expand to a multi-step workflow. Require a documented exception for any agent that can bypass a policy gateway, use a shared credential, or operate across multiple trust domains. This staged approach keeps the business moving without pretending that autonomy is free.
The right question is not whether an enterprise should use agentic AI, but which actions it should allow an agent to perform, with whose authority, and under what evidence. Secure data un-siloing makes the agent more useful because it can retrieve relevant knowledge from approved sources, yet that same connectivity increases the blast radius of a bad decision. Keep retrieval and action authorization tied to the source systems, use human review where consequences are high, and measure both productivity and security behavior. On 10 September 2026, that combination is more durable than any single model, prompt technique, or vendor feature.