The most important question about an AI agent is not which model it uses. It is what the agent is allowed to do when nobody is watching the screen. Every production workflow needs a permission boundary before it needs more autonomy.
Agents are useful because they can take action across systems. They read the inbox, check the CRM, draft the reply, update the ticket, prepare the invoice note, route the approval, and record what happened. That same usefulness creates risk when credentials are broad, actions are irreversible, or the approval path only exists in the prompt.
A safe agentic workflow treats permission as a product surface. The business should be able to answer who the agent is, which systems it can touch, which actions it can take, which actions require approval, and how to shut it down.
Give every agent its own identity
Shared employee credentials are convenient during a prototype and dangerous in production. If an agent uses a person's account, audit logs become muddy. Did the employee change the customer record or did the agent? Did the person send the message or did the workflow? Which policy applied?
The agent should have its own service identity wherever the system allows it. That identity should be scoped to the job. A billing-support agent does not need admin access to the whole CRM. A marketing-reporting agent does not need the ability to publish ads. A customer-memory agent may need read access to transcripts and invoices without permission to change either one.
If you cannot explain an agent's permissions in one paragraph, the boundary is already too wide.
Map permissions to jobs, not tools
Tool access is the wrong unit of design. "Can use Gmail" is too broad. "Can draft replies to known customers for order-status questions" is closer. "Can send a payment-change email" is a different permission with a different risk profile, even if it uses the same API.
Start by writing the job in business language. Then map the systems, records, fields, and actions needed for that job. Separate read, draft, propose, write, send, delete, purchase, refund, approve, and invite permissions. The difference matters because the failure modes are not equal.
This is also how teams avoid permission creep. A new workflow should not inherit yesterday's broad token because it was easy. It should get the smallest set of capabilities that let it complete the job and escalate everything else.
Approval gates belong outside the prompt
Prompts can tell an agent to ask for approval before risky actions. That is useful guidance, but it is not enforcement. The workflow layer should block high-impact actions unless an approved human decision is present.
The obvious gates are sending external email, deleting records, changing bank or payment instructions, issuing refunds, posting publicly, purchasing, granting access, and changing legal or HR language. A business may add softer gates too: unusual customer sentiment, low-confidence classification, missing source evidence, or a request from an unknown domain.
Good approval gates are specific. They show the source context, the proposed action, the policy reason, and the exact button a person is approving. "Looks good" is not a control. "Approve sending this reply to this recipient with this attachment" is.
Revocation has to be boring
Every agent needs a kill switch that operations can use without a code deploy. Disable the workflow. Revoke the token. Pause outbound actions. Drop the agent to draft-only mode. The right response depends on the incident, but the path should be documented before the incident exists.
Revocation also applies at smaller levels. A customer can be excluded from automation. A domain can be removed from the allowlist. A tool can move from write access back to read access. A single risky action can require review until the evals show the agent is ready again.
That flexibility matters because production agents improve over time. You should not have to choose between full autonomy and shutting the system off. A well-built control plane lets the business narrow the boundary, keep the useful parts running, and investigate with a clean audit trail.
Logs are part of the permission system
Access without audit is trust by memory. The workflow should record the input, source records, retrieved context, tool calls, policy decisions, approval events, final action, and downstream result. That trace is how a team answers what happened, why it happened, and whether the boundary held.
Logs also make improvement possible. If the agent keeps asking for approval on harmless cases, the policy may be too tight. If humans keep correcting the same draft, the workflow needs a better source or clearer rule. If a blocked action was the right call, it becomes a test case for the next release.
This connects directly to agent evaluation. Permissions decide what the agent may attempt. Evals decide whether the agent is good enough to earn more scope. Audit logs supply the evidence for both.
Autonomy should be earned in layers
A practical rollout starts read-only. Let the agent retrieve context, summarize work, and prepare recommendations. Then move to draft-only actions. Then allow low-risk writes in a narrow domain. Then allow selected sends or updates for known cases. High-impact autonomy comes last, after the workflow has logs, evals, and a record of boring outcomes.
The pattern is not slow for its own sake. It lets the business keep learning while the agent earns trust. People see where it helps, where it hesitates, where policy is unclear, and where the next permission boundary should be drawn.
Foundation builds agent workflows with identity, least privilege, approval gates, audit trails, and revocation built in. If your team is ready to automate work without handing an agent the master key, let's talk.