AI Agent Readiness: What To Define Before Giving An Agent Tools

TL;DR

"We connected it" is not "we controlled it." Connecting an agent to your tools — through MCP or any integration — is the easy part, and it's the part the demo shows. The hard part, the part nobody shows, is this: the moment an agent acts, you've created something that does things under some identity, and if you can't tell its actions apart from a person's, you can't review them, undo them, prove what happened, or stop it. That's not a model problem. It's an attribution problem, and most companies have it without knowing. Before you connect anything: if the agent does the wrong thing tonight, you must be able to prove it was the agent, name who owned it, and switch it off in minutes. No agent gets tools until that's true.

The pitch you'll hear, and what it skips

The agent pitch is capability and connection: it can use your tools, it plugs into everything through a connector, it works while you sleep. All true. All the easy half. Here's the half the pitch skips. Connection grants access; it decides nothing about what the agent may do with that access, and it tells you nothing about how you'd know what it did. An agent is different from a chatbot or an automation in exactly one way that matters here: it decides and then acts, on its own, using your systems. So connection is the demo. Attribution is the bill. A connector with no identity, no logging, and no off switch isn't an agent capability — it's your credentials in the hands of something that acts on its own, with no name on the actions.

The 2am test

Skip the seven-point checklist for a second. There's one test that decides readiness, and you can run it before you connect anything:

The agent takes a wrong, hard-to-undo action tonight, at 2am, with nobody watching. From your logs alone tomorrow morning: can you prove it was the agent and not a person? Can you say which human owned it? Can you switch off just the agent without taking down the team? Can you see exactly what it touched, so you can undo it?

Four yeses: you can talk about tools. Any no: you are not ready, no matter how well it ran in the demo — because the demo is the part that always works, and this is the part where the cost lives.

This is most companies, not the careless ones

This isn't a warning for sloppy teams. It's the default. In a January 2026 Cloud Security Alliance study, 68% of organizations said they cannot clearly tell an AI agent's activity apart from a human's. More than two-thirds. Hold that against the 2am test: for most companies "we'll just check the logs" is not a control they have — it's a sentence they assume is true and have never tested. The agent doesn't have to be reckless. The org simply never had attribution, and connecting an agent is the moment that gap stops being theoretical and starts being your problem.

What the seven questions are really about

You'll see readiness checklists — ours has one too — with seven questions: workflow, systems, actions, approvals, identity, logging, exceptions. Treating them as seven equal questions is the mistake. Five are configuration. Two are the gate: identity and attribution.

Here's why those two are different in kind. A wrong scope, a missing approval, an unclear owner — all recoverable, because you can see what happened and fix forward. An action you can't attribute is not recoverable: you can't review what you can't identify, can't undo what you can't trace, and can't learn from what you can't even prove the agent did. And one unattributable bad action poisons trust in all of them, because you can no longer say which actions were the agent's and which were people's. Identity and logging aren't items five and six on a list. They're whether the other five ever mattered.

The permission envelope, filled in

A blank envelope teaches nothing. Here's one filled in for a sensible first agent — one that drafts account research briefs by reading the CRM and the public web:

• Identity: its own service account, "svc-agent-research." Not an account executive's login. Every action carries that name.
• Reads: CRM account and contact records, and public web pages. Nothing else — not email, not files, not other customers.
• Writes: none. It drafts into a doc the account executive owns. It cannot write back to the CRM.
• Approval-required: not applicable — it has no write or send power to approve.
• Forbidden, always: sending email, writing to the CRM, opening files, touching any record outside the named account.
• Logging: every CRM read is recorded under svc-agent-research, kept 90 days.
• Pause owner: the RevOps lead, who can disable that one service account in a single click without affecting anyone else.

Now run the 2am test against it. Could you prove it was the agent? Yes — its own identity. Could it even do real damage? No — read-only, no send, no writes. That is what "ready" looks like, and notice it's boring on purpose. The first agent should be one where the 2am answers are obviously yes because you removed the powers that would make them hard.

The workflow still comes first

None of this — identity, logging, the envelope, the 2am test — makes a bad workflow good. It only makes the agent governable. An agent dropped into a process with no trigger, no owner, and no stop rule is still a bad deployment; you have just made it an auditable one. Bound the workflow first; that is its own piece of work. The agent is an actor inside a workflow that already works, not a substitute for defining one.

A safe first-agent sequence

When you do connect one, this order keeps the 2am answers easy:

1. It reads only approved sources.
2. It drafts internal output that a person owns.
3. A person reviews before anything leaves the building.
4. Every read and action is logged to the agent's own identity.
5. No writes, no sends, no external actions — those are earned later, one at a time.

What not to connect yet

• Anything that moves money, signs, sends to customers, or deletes — until identity, logging, and an off switch are real and tested, not assumed.
• Anything under a shared or human login. No own identity, no agent.
• Anything where "who switches this off right now, alone" has no name.
• Any "let it figure out what it needs" scope. The envelope is written first, or there is no envelope.

What not to do

• Don't confuse "we connected it" with "we can govern it."
• Don't hand an agent a person's credentials so it's "flexible."
• Don't treat the seven questions as equal. Identity and logging are the gate.
• Don't accept "we'll check the logs" until you've proven those logs can tell agent from human.
• Don't let the first agent be one that can do damage. Make the first one boring.

Related workflow pages

• Automation Governance Review
• Internal Search Assistant
• Task Intake Triage
• Account Research Briefs

Related field reports

• The Difference Between AI Adoption and AI Deployment
• What Human Review Points Are Needed In AI Workflows?

Where to go next

The AI workflow automation and AI implementation services pages explain how ADA bounds an agent inside a defined workflow before it touches a tool. The AI readiness assessment helps you run the 2am test honestly. To fill in a permission envelope for a specific agent use case, request an implementation review.

FAQ

What's the real blocker to using AI agents safely?

Not model quality and not connection. It's attribution: if the agent acts and you can't tell its actions from a person's, you can't review, undo, prove, or stop them. Run the 2am test before you connect anything.

We can plug an agent into our tools in an afternoon. Isn't the hard part done?

No — that's the easy part. Connecting it means it can act in your systems. Controlling it means that when it changes the wrong record at 2am, you can prove it was the agent and not a person, and undo only what it touched. Most teams do the first in an afternoon and never test the second until the morning it matters.

Why is agent identity such a big deal?

In a January 2026 Cloud Security Alliance study, 68% of organizations said they can't clearly tell an agent's activity from a human's. For most companies "we'll check the logs" is not a control they actually have — it's an untested assumption.

What should the first agent be allowed to do?

As little as possible: its own identity, read-only, no send and no writes, one named person who can switch it off. Make the first one boring so the 2am answers are obviously yes.

When does an agent need human approval?

Before anything that moves money, signs, sends to a customer, changes a record, or grants access. It can prepare the action; a named person approves it.

References

• Cloud Security Alliance: organizations cannot clearly distinguish AI agent from human actions
• Cloud Security Alliance: the AI agent identity crisis
• NIST AI Risk Management Framework
• OpenAI: ChatGPT agent controls and compliance logging