Before You Give an AI Agent Access: Seven Questions Every Business Leader Should Ask

An AI tool that drafts an email gives you something to review.

An AI agent that sends the email has taken an action on your behalf.

That difference matters.

Once a system can update a customer record, share a document or trigger a workflow, leaders need to understand its permissions as well as its capabilities.

Before connecting an agent to your business systems, ask seven questions.

1. What specific job are we asking it to do?

Start with a task you can describe clearly.

“Help our sales team” is too broad to assess. “Prepare a draft follow-up after an approved meeting summary is added to the CRM” gives you something concrete to test.

Define what starts the task, what information it needs and what a successful result looks like.

For an initial pilot, you might allow the agent to:

• Read an approved meeting summary.
• Identify agreed next steps.
• Draft a follow-up email.
• Present the draft to the account owner.

Sending the email could remain a separate, human-approved action.

This is an illustrative workflow, not a reported client result. Its value is that the boundaries are visible.

Ask: Can we explain the task and its limits in a few sentences?

2. What information can it access?

An agent may need some information from your CRM. That does not mean it needs access to every customer record.

Map the information required for the task. Identify what should remain outside its reach.

For the follow-up example, relevant information might include the contact’s name, the approved meeting summary and the account owner. Unrelated customer records, confidential negotiations and payment information may serve no purpose.

Ask the person configuring the system to explain its effective access in plain language. Check what the connection actually permits.

Where the platform supports it, use restricted permissions and a dedicated identity so the agent’s access can be reviewed and withdrawn separately.

Ask: What can this agent see that it does not need?

3. What is it allowed to change?

Reading information and changing it are different responsibilities.

An agent that summarises a customer record has a different risk profile from one that changes the opportunity stage or overwrites contact details.

List the actions separately:

• Read.
• Create a draft.
• Add a record.
• Edit an existing record.
• Send or share information.
• Delete information.

Decide which actions are necessary for the pilot. Keep the others unavailable where the system allows.

A broad permission granted during setup can outlast the original reason for granting it. Include access reviews in the operating plan.

Ask: Which changes could happen without a person noticing first?

4. Which actions need human approval?

“Keep a human in the loop” needs a practical definition.

Who is the person? What are they reviewing? What information will they see? What happens if they do not respond?

For a customer email, the reviewer may need to check the recipient, attachments, claims, commitments and proposed next steps.

An approval screen should make the proposed action understandable. A button labelled “Approve” is not enough if the reviewer cannot see what will happen.

Decide which situations require escalation. These might include an unfamiliar recipient, a request outside the agreed task or a proposed change to sensitive information.

For higher-consequence actions, ask how the system enforces approval. An instruction in a prompt should not be your only control.

Ask: Can the agent complete this action if nobody approves it?

5. How will we test errors and unexpected instructions?

A successful demonstration shows that a workflow can work under the conditions demonstrated.

Before wider use, examine what happens when those conditions change.

For the follow-up example, test a meeting summary with a missing name, conflicting next steps or an incorrect email address. Check whether the system asks for clarification, stops or proceeds.

Also consider the material the agent reads. An email, webpage or document can contain instructions that conflict with the task you gave it. Your technical team should assess how the system handles that situation.

Use fictional or appropriately approved information during testing. Record the expected behaviour before running each test.

Useful questions include:

• Does it stop when essential information is missing?
• Does it recognise that a request is outside its task?
• Can it accidentally repeat an action?
• Does it make an error visible to the responsible person?

Ask: What evidence shows that the boundaries work when something goes wrong?

6. Who can stop it—and how will we recover?

Name an owner before the pilot begins.

That person should know how to pause the workflow, who can revoke access and where to find a record of its actions.

Consider recovery separately from stopping.

You may be able to restore an edited record. An email already sent to the wrong recipient is harder to undo. The recovery plan should reflect those differences.

Agree what information needs to be logged, who may inspect it and how long it should be retained. Logs themselves may contain business or personal information, so access matters here too.

Run through a simple scenario: the agent performs the wrong action. Who notices? Who responds? How do they establish what happened?

Ask: If we needed to stop this now, would the responsible person know what to do?

7. What evidence would justify giving it more responsibility?

Avoid treating increased autonomy as the automatic next step.

An agent may be useful as a drafting assistant even if sending or editing remains subject to approval.

Measure the whole workflow, including checking, correcting and maintaining it.

For a pilot, record:

Measure	What to examine
Quality	Accuracy, completeness and suitability of the output
Human effort	Time spent reviewing and correcting
Exceptions	How often the system needs help
Control failures	Actions outside the intended boundaries
Business value	Whether the process improves in a meaningful way

A small pilot with no observed incidents provides limited evidence. Consider the range of situations tested and the consequences of failure before expanding access.

Ask: What have we learned that supports the next change in permissions?

Use the 5Ps before choosing the agent

My 5Ps framework provides a way to connect these questions to the organisation.

People: Who owns the workflow, uses it and reviews its actions?

Process: Which steps are clearly defined, and where are the exceptions?

Platforms: Can the chosen tools enforce the permissions and approvals you need?

Proprietary Data: Is the information suitable, current and appropriately accessible?

Products & Services: How will the change improve what the organisation delivers?

The framework helps keep the discussion tied to the work. A capable tool still needs an appropriate task, suitable information and clear responsibility.

Bring relevant examples into the discussion

My work through AI Ireland and the AI Awards provides a window into how organisations across Ireland are applying AI.

Those examples help generate useful questions. Which part of a process changed? What information did it depend on? What would your organisation need before attempting something similar?

The business lessons from AI Awards finalists are a starting point for that discussion. A finalist’s experience does not establish that the same approach will work in another organisation.

Preparation for a leadership workshop can also include an AI readiness survey. That helps identify your team’s experience, uncertainties and priorities before deciding which examples and exercises will be most useful.

A short brief before your first agent pilot

Before connecting an agent to a live system, write down:

• Its task and what is outside scope.
• The information it can access.
• The actions it can perform.
• The approvals it must obtain.
• The tests it must pass.
• Its owner and stopping procedure.
• The evidence you will review before changing its permissions.

If the team cannot answer one of those points, make it a preparation task.

The aim is to give the agent enough access to do a useful job, with controls that match the consequences of getting it wrong.

Planning an AI agent discussion with your leadership team?

Bring one process you are considering.

We can examine it through the 5Ps, identify the decisions that need human ownership and define a practical next step.

Read what an AI leadership workshop should deliver, or discuss a workshop for your team.