Building Secure Agentic AI Workflows: Tools, Permissions and Memory

An agentic workflow is one where an LLM decides which actions to take: calling APIs, querying databases, browsing, running code and calling other agents. This autonomy is the source of the value and of the risk. A chatbot that gives a wrong answer is an inconvenience; an agent with write access that follows a malicious instruction is an incident. This article describes the controls that make agents safer to deploy.

Start with a capability map

List every tool the agent can use, what each tool can read and change, and what credentials it runs under. A simple table forces clarity:

Irreversible and externally visible actions deserve the strongest controls. If a tool is not needed for the use case, remove it. Every tool is attack surface.

Principle 1: least privilege, per user

Agents should act with the user's permissions, not a shared administrator identity. Otherwise, any user (or any attacker who injects instructions through content) can reach everything the service account can. Pass the user's identity to downstream systems and let those systems enforce authorization. This avoids the "confused deputy" problem, where a privileged component is tricked into acting for an unprivileged party.

Principle 2: gate consequential actions

Classify actions by impact. Low-risk reads can run automatically. Medium-risk writes might require logging and rate limits. High-risk actions (payments, deletions, external messages, permission changes) need explicit human approval showing the exact parameters. Make approvals specific; a generic "continue?" button invites reflex clicking.

Principle 3: sandbox code execution

If an agent runs code, do it in an isolated environment: a container or micro-VM with no access to host credentials, a read-only base filesystem, resource limits, no network by default (or an allowlist), and short lifetimes. Never run model-generated code in your application's process or with its credentials.

Principle 4: validate tool inputs and outputs

Define each tool with a strict schema and validate arguments in code before executing. Reject unexpected fields, enforce ranges and formats, and parameterize database access. Treat tool results as untrusted too, because they can carry injected instructions: a web page returned by a browsing tool may contain text aimed at the agent. See prompt injection defenses.

Principle 5: secure retrieval and vector stores

Retrieval-augmented generation (RAG) systems store document embeddings in a vector database. Common failures:

• Missing access control: a user's query retrieves chunks from documents they cannot normally read. Store permissions as metadata with every chunk, and filter at query time using the caller's identity.
• Cross-tenant leakage: use separate indexes or enforced tenant filters. Test with tenant-crossing queries.
• Poisoned documents: anyone who can add content to the index can plant instructions. Control who can write, and track provenance for each source.
• Sensitive data in embeddings: embeddings can leak information about their source text; apply the same retention and access rules as the original data.

Principle 6: limit loops, cost and scope

Agents can loop, retry endlessly or call expensive tools repeatedly. Set maximum steps per task, maximum tokens and spend per user and per day, timeouts, and circuit breakers. These protect against both bugs and denial-of-wallet attacks, in which an attacker intentionally drives up your model or API costs.

Principle 7: log and audit

Record each step: the prompt, the tool called, the arguments, the result and the identity of the user. These logs support incident response and let you answer "what did the agent do and why?" Redact secrets and personal data in logs, and apply retention limits.

Principle 8: multi-agent systems

When agents call other agents, treat each boundary as a trust boundary. Messages between agents are inputs, not commands. Give each agent its own narrow permissions, and avoid architectures where one compromised agent can instruct a more privileged one.

Pre-launch checklist

1. Capability map reviewed and unnecessary tools removed.
2. Per-user credentials; no shared admin tokens.
3. Human approval on irreversible actions.
4. Code execution sandboxed.
5. Strict schemas for tool inputs; outputs treated as untrusted.
6. Retrieval enforces document-level permissions.
7. Step, token and spend limits in place.
8. Audit logging and an incident runbook.
9. Adversarial tests covering injection, data exfiltration and tool misuse.