--- title: "Giving an AI Agent the Access It Needs and No More" description: "Which accounts, folders and systems an AI agent should reach, how to grant that access safely, and how to review the list before it quietly grows." date: 2026-11-11 updated: 2026-11-11 topic: "Strategy and Leadership" author: Wave Agency canonical: https://waveagency.com/blog/ai-agent-access/ --- # Giving an AI Agent the Access It Needs and No More The fastest way to set up an AI agent is to sign it in as yourself. Your email, your shared drive, your accounting login, your admin rights on the website. Everything works on the first try, and that is the problem. You have just given a piece of software every key you own, and nobody, including you, could list what it can now touch. Access is the part of an agent project that gets the least thought and decides the most. An agent with narrow access that makes a mistake makes a small one. An agent with your login that makes the same mistake can make it everywhere at once. ## Start with the job, not the systems Before anyone grants anything, write the agent's job in one or two sentences. "Answer booking requests from the website and add them to the calendar." "Match vendor invoices to purchase orders and flag the ones that do not match." Then walk through the job step by step and note every place the agent has to look or act. The booking agent needs to read the website inbox, read and write the calendar, and send a confirmation email. It does not need the accounting system, the shared drive or the customer list beyond the names on the calendar. That list is the agent's access. Anything not on it stays off. If the job grows, the list grows with it, on purpose. ## Give it a login of its own An agent should never run under a person's account. Give it its own identity in every system it uses: its own email address, its own user in the calendar, its own account in the accounting software where the software allows it. This does three things at once. - **You can see what it did.** Every change in the system's own history shows the agent's name, not yours or a colleague's. - **You can limit it.** Most business software lets you set what each user can do. A separate user can be given a narrower role than any person on the team. - **You can switch it off.** Disabling one account stops the agent in that system without locking out the person whose login it would otherwise have borrowed. If a system only allows one login per company, that is worth knowing before the agent goes near it. It may mean the agent should prepare work there for a person to finish rather than act in it directly. ## Read is not the same as write For each system on the list, decide what the agent actually needs to do there. **Read only** is enough more often than people expect. An agent that answers questions about order status needs to look up orders, not change them. An agent that drafts a weekly report needs to read the numbers, not edit them. **Write** belongs only where changing something is the job: adding a booking, updating a ticket, filing a document into the right folder. **Delete** almost never belongs on the list. Archiving covers most of what people mean by cleaning up, and it can be undone. We covered why in [what an AI agent should never do without asking](/blog/what-an-ai-agent-should-never-do-without-asking/). Files work the same way. Give the agent one folder or a short list of them, not the whole shared drive, which collects years of contracts, payroll exports and personal records that no agent doing customer service has any reason to open. ## Keep the keys out of the instructions Agents often connect to other software with API keys or tokens, which are long passwords issued to software instead of people. Treat them exactly like passwords. - Store them in a password manager or the platform's secure settings, never pasted into an email, a chat or a shared document. - Give each agent its own key, so you can cancel one without breaking the others. - When a system lets you limit what a key can do, limit it to the same read or write list you wrote above. - Note where each key lives and when it was issued. A key that sits in an old message thread is a key anyone with access to that thread now holds. ## Review the list, or it will grow Access only ever drifts one way. Someone grants a little more for one extra task, and nobody takes it back. A year later the booking agent can read the payroll folder and nobody remembers why. Put a short review on the calendar, monthly at first and quarterly once things are steady. It takes a few minutes per agent: 1. Is the agent's job still the one written down? 2. Does every system on its list still serve that job? 3. Has anything been added since the last review, and was it meant to stay? 4. Did the logs show it using everything it has? Access it never uses is access it does not need. 5. Are its keys still stored where they should be, and has anyone left who knew them? When an agent is retired or replaced, offboard it the way you would a person: disable its accounts, cancel its keys and remove it from shared folders the same day. The [small business cybersecurity checklist](/blog/small-business-cybersecurity-checklist/) makes the same point about former employees, and it applies just as much to software. ## A quick check before you switch one on - Is the agent's job written in two sentences? - Does it have its own login in every system it uses? - Is each system marked read, write or neither? - Is its file access limited to named folders? - Are its keys stored safely and issued to it alone? - Is a review date on the calendar? - Can you disable it everywhere in under five minutes? If any answer is no, fix that first. Granting access carefully is far easier than working out later what an agent could have reached. ## How we set it up Our [AI Workforce](/ai-workforce) practice builds agents trained on your workflows, and each one is sandboxed and scoped to the systems its work needs, with a permanent log in plain language. On [Wave Workforce](/wave-workforce), the platform they run on, your own team sets limits, reads the log and can stop one agent or the whole crew from a console. Because we also do [cybersecurity and data protection](/technology/cybersecurity-and-data-protection) as a service line of its own, the people scoping an agent's access are people who do that work every day. Planning your first agent? [Book a call](/book) and bring the list of systems you think it needs.