How much access should you give an AI agent? A small-team guide

Start with a job and an access record

Write a sentence describing the output you want. For example: “Prepare a weekly list of overdue internal tasks for the operations manager.” Then list the inputs that output requires. A request to “help with operations” is too broad to turn into a useful permission decision.

For each connection, record its business owner, account identity, allowed records, permitted actions, and review date. Add the person who can disconnect it. Keep this record free of passwords and tokens; it should describe access without becoming a collection of secrets.

Our recommendation is to approve this record before connecting production data. When the job changes, update the record and review the added access. Avoid granting permissions merely because a later feature might need them.

Separate what the agent can see from what it can do

OWASP recommends limiting agent tools and downstream permissions, with authorization enforced outside the language model. A tool that reads a record and a tool that deletes it have different consequences. A prompt asking the agent to be careful does not enforce the same boundary as a denied operation in the connected system. ^[1]

Ask your implementer two concrete questions: which records can this connection retrieve, and which operations can it perform on them? A read-only connection still needs a data boundary. For your own plan, identify excluded folders or projects as explicitly as included ones.

For Google OAuth integrations, Google recommends requesting the smallest scopes needed when a feature needs them. Its guidance also says an application should disable relevant functionality when the user denies a scope. Other providers have their own permission models; check the exact connector before assuming comparable controls exist. ^[2]

Worked example: a weekly task digest

Consider a hypothetical six-person maintenance business. Its operations manager wants a Monday digest of overdue work in the internal Scheduling project. The digest needs task title, due date, status and assigned staff member. It does not need payroll files or customer attachments. These are example requirements, not a customer story or measured result.

Its proposed access record says: input is the Scheduling project; allowed operation is reading the four named fields; output is a draft digest in an internal review queue. The manager reviews the draft and distributes it manually. The automation has no business requirement to change due dates or invite users.

The implementer must check whether the selected system can enforce that plan. If its connector can only read every project, the manager should review a narrower export or a filtered integration before proceeding. Merely hiding projects in the agent’s instructions would leave the underlying access broader than the plan.

The useful addition to a typical permissions checklist is a matching denied-request test. In a test environment, ask for a task from an excluded project and attempt a harmless update to a test task. Expected outcomes are a denied read and a denied write. Record the actual response and check that the test task remains unchanged. If either operation succeeds, pause the connection and fix its access boundary.

Test the boundary before the first live run

Use invented records to test an allowed task, an excluded record and a missing permission. Have the implementer exercise the connection directly where practical. An agent declining a request in conversation does not establish that the underlying connection would refuse it.

Also test a source document containing an instruction to retrieve excluded information. Record whether the attempted operation is blocked. This is a practical acceptance check, not a security certification: passing a few examples cannot establish that every attack will fail.

For actions that require a person’s decision, specify the exact item the person will review and how the approved item reaches the executing tool. OWASP recommends approval for high-impact actions. ^[1] Our guide to [human approval in AI workflows](/blog/ai-agent-human-approval) helps you map those decisions before adding a write-capable connection.

Plan removal and understand the limits

Google’s OAuth guidance calls for secure token storage and revoking and deleting tokens when they are no longer needed. ^[2] Ask the implementer to document the provider-specific removal procedure. A paused schedule alone should not be your evidence that credentials have lost access.

Our suggested shutdown drill is to pause new runs, revoke the test connection, and attempt an ordinary permitted read. Confirm that it now fails. Then inspect pending work before deciding whether to reconnect. Assign one owner to track completion so an abandoned pilot does not leave an unexplained connection behind.

Removing access does not by itself establish that previously retrieved copies have been deleted. Review stored outputs separately with the relevant system owner. Permission design also does not validate the accuracy of an AI summary; your workflow still needs checks for its business output.

Before launch, retain the approved access record and test outcomes, then review them when the workflow or connector changes. If you need help turning a job description into a permission plan, use the [Croissant contact form](/#contact) and describe the systems and intended output. Leave credentials and private records out of the enquiry.

Implementation checklist

• Define one business output and name its owner.
• List allowed records, required fields and excluded data.
• List each permitted action and its approval requirement.
• Confirm the connector can enforce the proposed limits.
• Test allowed and denied operations with invented records.
• Assign a connection-removal owner and test revocation.
• Save the access record and review it when the workflow changes.