AI may own a lot more of the work, but accountability and responsibility still rest with you

Actively check the AI’s reach and access — not what it remembers or assumes. Look for its connected tools and accounts; its files, projects, memory and shared workspaces; any browser or computer access and active logins; its schedules, automations and triggers; other agents or helpers it can call on; what each tool can read, change, send, delete or share; what information it can move between systems; and what can start or continue work automatically. The goal is a factual map of the AI’s current reach, capabilities and existing permissions.

Because the results can reveal sensitive information about your accounts, access paths, connected services, security controls, and operational environment, treat the output as confidential security information. Review it carefully, limit who can access it, and remove or redact sensitive details before sharing it outside your trusted team.

The objective is to identify potentially sensitive access, permissions, connected systems, identities, and persistence mechanisms visible to the agent.

The scan is non-destructive and does not intentionally modify data, change settings, execute transactions, or actively probe external systems. It is not a penetration test, exploit test, compliance certification, or complete security assessment, and it may not identify every risk or vulnerability.

Once you know what the AI can technically do, decide what it is actually allowed to do for you. Set limits on what work it may perform; which tools and information it may use; what it may do on its own and what requires approval; spending, volume, time and recipient limits; what it may change or make official; when it must stop or ask; whether it may delegate to other agents; how long the permission lasts; and what it must never do.

A discovery question and a grant are both instructions to an AI that may already reach your accounts, files, tools or browser. Don’t trust the AI to police itself, don’t treat a prompt as a security boundary, don’t trust a grant because of who wrote it — and don’t trust us blindly either. Trust what you can check: read the instructions before you send them; where a discovery question publishes a checksum, compare it with the one you copied; read the letter, not just the file; keep discovery separate from permission — a scan never grants anything; and remember that only your AI’s own permission settings, or a system that checks each action before it runs, actually enforce a limit.

Rules about permissions and authority are extra instructions. They do not replace the security, passwords, or approval settings of your apps or the AI company. AI systems can ignore instructions. You remain responsible for confirming the agent is configured the way you expect.

Asking an AI what it can reach is, in effect, a light vulnerability scan of your own setup: its answer can list accounts, logins, token and key names, network rules, and what it could not reach. Its answers can name your accounts, email addresses, files, people and other personal information. Be careful where you paste, share or store them.

A grant decides which actions the AI may take for you. Whether the AI company keeps your conversations, trains its models on them, or what happens to your files and ideas (your IP) is a separate question, answered by the provider’s own data controls in your ChatGPT, Claude or Grok settings. Business and enterprise plans usually restrict this further by default; on a personal plan, check those settings yourself. A grant can say “never share files with others”, but it cannot change what the provider itself does with your data. It matters most when the data is someone else’s, or confidential to your work.

Work is no longer just a workflow: people, AI agents, software and machines work across different structures, handoffs, decisions and degrees of autonomy. Before you connect a tool or grant an agent anything, write down the six things that define it — what the work is, how it progresses, who participates, what information a decision rests on, what gives a participant the go-ahead to act (the rule inside the work — not the same as what you allow the agent in the grant), and what makes a result official. A work system is that description: the recurring shape of the work, not the software running it, and it is what lets you see, compare, redesign, simulate and eventually run it. If you cannot say what “done” means, and who is allowed to call it done, do not automate it.

No catalogue of failures is final. For any grant, check where the agent can exceed what you allowed, expose information, follow instructions hidden in a file or message, make an incorrect decision or treat a wrong output as official, or carry that error into another connected system. New models, tools, attack patterns and forms of autonomy keep changing what matters, so revisit these checks whenever you add a tool, a login or an automation.

AI does not change all work in the same way. Take the tasks that make up the role and, for each one, mark whether the work leaves the person (substitution), stays and goes faster (augmentation), or shifts which skills matter most. They pay back differently: work that leaves is labour saved, at what that person’s time costs; work that stays and speeds up is extra output, and counts only as far as it is actually used. Neither is free — take off what the agent costs to run, and what remains is the net value. Count each task once, never as both. Use that to decide what to grant and what stays with the person; it is not a forecast, but an input to the boundaries you set.

An agent that can reason, plan, use tools, and act still has no grant until the organization gives it one, and it does not inherit one by taking over a task a person was allowed to do. A recommendation to pay a claim is not the payment, a diagnosis is not a discharge, and a model’s confidence is a property of the model, not a permission. Every way of working has to say what gives a participant the go-ahead to act and what makes the result official. On a fixed route, finishing a step starts the next and the last step settles it. On a board, a market, a committee, or a peer network, those two answers are most of the design, and changing them changes who may act, what must be reviewed, who is accountable, and how a failure lands. “An agent could do this” and “an agent may do this” remain different questions after the economics have moved.

If work leaves a fixed route for an agent-directed team or a shared environment, the organization still has to know who may act, what authority they hold, what requires review, what happens when something fails, and what commits the result.