Agentic AI for agencies: permissions matter more than prompts

“Write a proposal” is a generation task. “Find the right client folder, pull last quarter’s report, update the pricing table, send the draft to the client, and log the result” is an agentic workflow.

The difference is not marketing language. The second workflow can read, decide, write, and communicate. That means the most important design question is not how to phrase the prompt. It is what the system is allowed to do when the prompt, source, or tool behaves unexpectedly.

Four permission levels

1. Observe

The agent can read an approved source and return a plan or draft. It cannot change anything. This is the right first step for a new workflow and a good default for sensitive client work.

2. Prepare

The agent can create a draft, proposed change, or queued action in a workspace. A person reviews it before anything external happens. Most agency automation can stay at this level and still save meaningful time.

3. Commit

The agent can update a file, move a task, or change a record. Use narrow scopes: one client, one project, one folder, one time window. Make the action reversible and keep a visible log.

4. Communicate

The agent can send an email, publish a page, invite a collaborator, or submit something to a third party. Treat this as a separate escalation, not a small extension of write access. Require approval, a recipient preview, and a record of what was sent.

This ladder makes it easier to say “yes” to useful automation without giving a new system the keys to every client workspace.

Why prompts are not a security boundary

Prompts are instructions. Permissions are controls. A prompt can be misunderstood, a source document can contain hostile instructions, a connector can change, or the model can choose an unexpected path. If the system has broad access, a small mistake can become a large action.

The OWASP GenAI Security Project’s 2026 Top 10 reflects this shift toward real-world incidents and agentic systems. Its advice is a useful reminder to control what an AI application can reach and do, not just what it is told.

Build an approval boundary

An approval step should show the action, not merely say “the agent is ready.” For a client email, show the recipient, subject, attachments, and final text. For a file change, show the file, the proposed diff, and the actor whose account will be used.

Let the reviewer reject, edit, or ask for a new plan. A one-click approval that hides the details is a rubber stamp.

Test the failure path

Before you give an agent write access, test:

• an incomplete brief;
• a conflicting instruction in a source document;
• a file with the wrong client name;
• an expired or revoked permission;
• a duplicate request;
• a tool that returns stale data;
• an action that fails halfway through; and
• a user who asks for something outside the approved scope.

The desired outcome is not “the model never makes a mistake.” It is “a mistake stays contained, visible, and reversible.”

Keep the audit trail useful

Log the request, source references, plan, tools called, permissions used, outputs, approvals, and external actions. Keep enough context for a person who was not in the room to understand what happened.

Do not rely on an agent’s own summary as the only record. System logs and the final artifact should be able to disagree visibly when they need to.

An agency pattern that works

Use agents for preparation and routing first: turn notes into a draft, classify a request, check that an intake form is complete, or suggest the next document. Keep final recommendations, pricing changes, legal language, and external sends behind a human approval.

Docsiv’s editors, comments, sharing, approvals, and version history give teams places to inspect and own the work. The goal is not to remove people from the workflow. It is to give them a clearer point of control.