How to Set Up Approval and Permissions for AI Agents in Your Revenue Stack

An approval gate is a checkpoint between an agent deciding to act and that action executing against a live system. The agent drafts the action, a CRM field update, a ticket, a follow-up email, and the draft lands in a pending state where a named human approves it, edits it, or rejects it. That is different from a notification, which tells you after the write happened, and from a log, which tells you only if you go looking. The OWASP Top 10 for LLM applications lists excessive autonomy, meaning high-impact operations run without confirmation, as one of three root causes of its Excessive Agency risk, and its mitigations include human-in-the-loop control that requires "a human to approve high-impact actions" before they are taken. AWS says the same in its Well-Architected guidance for agentic workflows, which closes its implementation steps with user confirmation of agent actions. The gate is where independent frameworks converge.

Human role-based access assumes the account holder can be trained, warned, and held accountable, so organizations tolerate broad grants. None of that transfers to an agent. An agent is a non-human identity that executes at machine speed, holds credentials without judgment, and can be steered through its inputs by prompt injection or poisoned context in ways no employee can. The scale problem is already here: CyberArk's 2025 Identity Security Landscape, a survey of 2,600 security decision-makers, found 82 machine identities for every human, with 42 percent of those machine identities holding privileged or sensitive access. Yet 88 percent of organizations still define a privileged user as human only, and 68 percent say they lack identity security controls for AI. If your agent logs in as a person, it inherits everything that person can touch, which is exactly the excessive permissions failure OWASP warns about. Scope for what the workflow needs, not for what the human it assists could do.

The first implementation decision is that the agent gets its own account, never a borrowed human login and never a shared service account with a master API key. Microsoft has made this concrete in Entra Agent ID, where each agent is a distinct identity object created from a reusable blueprint, holds no standing credentials of its own, and records a human sponsor who is accountable for it, so admins can apply policy to every agent of a kind or disable them all in one action. Salesforce takes the same shape in Agentforce, where an agent runs as its own agent user with permission sets assigned to that user, and security guidance warns against sharing permission sets across agents because widening one agent silently widens the rest. A dedicated identity buys you three things: writes attributed to the agent in the audit trail, the ability to shut off one agent without locking out a person, and permissions you can actually reason about.

Least privilege for agents is mechanical, not aspirational. Give read-only connections wherever the workflow does not write. Use granular OAuth scopes instead of full API access, so an agent that logs call notes holds contact and activity scopes but nothing that can delete a record. In AWS terms, agent execution roles get scoped policies naming specific resources, capped by permissions boundaries that set the maximum any later edit can grant. In CRM terms, apply object-level and field-level security to the agent user so a forbidden field is unwritable rather than merely unmentioned. The rule that matters most comes from OWASP: enforce authorization in the downstream system, not in the model. A system prompt that says do not delete records is a request; an API token that lacks the delete scope is a control. Assume the instructions will eventually be ignored, hallucinated around, or manipulated, and make the damaging call impossible instead of discouraged.

Gate by consequence, not by blanket rule. The Cloud Security Alliance's draft agentic profile of the NIST AI Risk Management Framework separates agent tools into read, write, and execute classes with controls that escalate accordingly, and describes autonomy tiers running from fully supervised to autonomous within hard boundaries. Translated to a revenue stack: reads, such as pulling a record or summarizing a call, run free. Reversible low-consequence writes with a full audit trail, such as logging an activity or creating a task, can run autonomously once the agent has a track record. High-consequence or hard-to-reverse writes wait for sign-off: opportunity stage and amount changes, close dates, renewal and contract fields, anything customer-visible like an outbound email, and record merges or deletions. Anthropic's framework for trustworthy agents lands in the same place, agents work independently but humans keep control ahead of high-stakes decisions, and its own coding tool ships read-only by default and asks before modifying anything.

Here is a concrete pattern for CRM writes. The agent connects with its own identity: an Agentforce agent user with dedicated permission sets, an integration user behind a Connected App for API-driven agents, or a HubSpot app granted only the scopes the workflow uses. Start from zero; as one Agentforce security review puts it, "Agents should only have the permissions they absolutely need to perform their intended tasks." Then write the policy per field class. Tasks and activity logs write straight through. Stage, amount, close date, and forecast fields produce a drafted change that shows the old value, the new value, and the evidence behind it, such as the call excerpt that justified the update, queued for the account owner to approve. Delete is not granted at all, so the worst case is a wrong value you can see, not a missing record you cannot. After approval, the write executes and is read back to verify it landed, logged against the agent's identity.

An approval gate only protects you while reviewing is easier than ignoring. Show the diff, not the payload: old value, new value, source evidence, one glance. Keep one queue instead of five tabs, allow edit-in-place so a wrong amount is fixed in seconds rather than bounced, and let reviewers act in batches. Deliver the nudge where people already work, Slack or the inbox, while recording the decision centrally. Give the queue a latency budget, because a gate that adds a day of delay teaches the team to bulk-approve on Friday afternoon, which is no gate at all. Then guard against drift. Scope sprawl, where an agent accumulates permissions past its original purpose, is a named pitfall in Agentforce security writing, and CyberArk's data shows most organizations do not even count machine identities as privileged. Review each agent quarterly: list the scopes it holds against the scopes it used, and cut the difference.

Pick one agent and one workflow. Create a dedicated identity for it, enumerate every tool and scope it can reach, and classify each as read, write, or execute. Default every write to gated, then promote individual write types to autonomous only after a stretch of clean approvals, so autonomy is earned per action, not granted per agent. Wire every action, approved or rejected, into an audit trail keyed to the agent identity, and put a quarterly permissions review on the calendar before the first one is missed. This is standard build work for a GTM engineering on subscription partner, and it is how Mindlyft ships every workflow: ASTRA drafts the CRM updates, tickets, and follow-up emails after a call, and anything above the consequence line you set waits in a review queue for a human yes. The first workflow is free, then $5,995 a month, at mindlyft.in.