Practical AI · 3-minute read
An AI that drafts an awkward email gives you something to edit. An AI that sends it to 600 customers gives you an afternoon. The difference is permission.
An AI agent can use connected tools to take steps toward a goal. That might include reading files, changing records or publishing content. Its access and limits deserve the same attention as its clever demonstration.
Write down the permitted actions
Westvale Creative, a fictional marketing studio, wants an agent to prepare client social posts. The proposed pilot lets it read one folder of approved campaign material and save drafts in a review queue. It cannot publish, change budgets or browse unrelated client folders.
That boundary belongs in the connected system’s permissions. Writing ‘do not publish without approval’ in a prompt is an instruction to the model. Removing publishing access is a control the model cannot simply reinterpret.
If the team later enables publishing, approval must cover the actual text, media, destination account and timing. A changed draft needs a fresh review. The tool should stop if the approved action cannot be verified.
Use a small control checklist
Access: exactly which files and systems can it read or change?
Approval: which actions require a person, and what does that person inspect?
Limits: which recipients, spending amounts, action counts and run times are allowed?
Record: where can a reviewer see the inputs, approval and completed actions?
Stop: who can pause execution, revoke access and reconcile work already done?
OWASP identifies excessive functionality, permissions and autonomy as sources of excessive agency risk. Its guidance includes limiting permissions and requiring human approval for high-impact actions. [1]
Review this proposed agent workflow: [steps]. Draft a permission and approval table showing each action, required access, allowed scope, human reviewer, limit, log entry and stop condition. Identify controls that must be enforced by the connected system rather than a prompt. Flag unknown capabilities. Include tests for changed content after approval, an unauthorized destination and a request hidden inside a source document.
Test the stop before the launch
Use a test account and fictional content. Have the technical owner verify that forbidden actions actually fail. Try a source document that tells the agent to ignore its instructions. Source material is information to evaluate, not permission to expand the job.
Test the stop procedure while work is running. Check queued actions and anything already completed. Revoking access cannot unsend a message, and pausing one screen may not cancel a separate scheduled job.
The human reviewer still checks accuracy, confidentiality and unfair or misleading messaging. If the system cannot enforce a needed boundary or give reviewers a usable record, narrow the pilot to drafting. That can still remove useful work from someone’s day.
Your turn: If an agent made the wrong move in your business, who could stop the next one?
Source [1]: OWASP: LLM06 Excessive Agency. Permission limits and human approval. The studio, proposed pilot, checklist and tests are original editorial guidance, not a verified configuration for a particular product.
