Agentic workflows need permissions, not just prompts

The moment a language model can call tools, it stops being a text generator and becomes an actor in your system. It can read records, create tickets, trigger deployments, send messages. Most of the guidance about "agent safety" focuses on the prompt: tell the model to be careful, to ask before acting, to stay within scope. Prompts are useful. They are not a security control.

We design agentic workflows the way we design any service account: with permissions the runtime enforces, not intentions the model is asked to honour.

An agent is a principal

Every agent run executes under an identity. That identity has a role, the role has a scope, and the scope is enforced by the same authorization layer that governs human users and services. If a support agent's role cannot delete customer records, no prompt, injection or hallucination will let it. This is the single most important design decision, and it is entirely conventional engineering.

Two consequences follow. First, agents inherit the organization's existing RBAC model rather than requiring a parallel one. Second, audit logs record the agent identity alongside the human who initiated the workflow, so accountability is preserved.

Tools declare what they do

Each tool an agent can call carries metadata: what it reads, what it writes, whether it has external side effects, and what permission it requires. The runtime filters the tool list per run based on the agent's role, so the model never sees a tool it cannot use. That reduces both risk and confusion: models perform better with fewer, relevant tools.

Tools with side effects are categorized by blast radius. Reading a record is low. Creating a draft is medium. Sending an external email, changing a permission or triggering a production deployment is high. Category determines the approval policy.

Approval gates are part of the workflow

High-impact actions pause the workflow and request human approval with full context: what the agent intends to do, why, and what it observed to reach that decision. The approver sees the proposed tool call and its arguments, not a summary. Approval, rejection and timeout are all recorded.

This is where the design pays off. Because approvals are a platform feature rather than a prompt instruction, they cannot be talked around. And because the context is structured, approvals are fast: most take seconds.

Everything is logged as a trace

An agent run is a tree: the initial request, each model call, each tool call with arguments and results, each approval, and the final outcome. We store the full trace, with token counts and latency, linked to the user and to any records the run touched. Traces serve three purposes: debugging, evaluation, and audit. When someone asks why an agent did something, the answer is a query, not an investigation.

Budgets and kill switches

Agents loop. Loops cost money and occasionally go wrong. Every run has a budget in tool calls, tokens and wall-clock time, and the runtime terminates runs that exceed it. Every agent type has a kill switch that disables it fleet-wide in seconds without a deployment. Both are boring. Both have been used.

Prompts still matter

None of this makes prompt design irrelevant. A well-designed prompt produces better decisions, fewer wasted tool calls and clearer explanations for approvers. The distinction is about what you rely on. Prompts improve behaviour. Permissions bound it. Build the boundary first, then make the behaviour good.