What to Tell Your IT Team Before an AI Agent Project

To involve IT well in an AI agent project, brief them before a vendor is chosen and before any account is created. Tell them what role the agent will play, which systems it will touch, what identity it will use and who will support it afterward. IT then reviews a defined scope instead of discovering one at the last minute.

Key takeaways

• Brief IT while the scope can still change, not when a service account or firewall exception is already requested.
• Give IT a one-page description of the role, the systems, the data and the actions the agent may take.
• Ask for a dedicated agent identity with narrow permissions, never a borrowed employee login.
• Agree in writing who handles incidents, access changes and user questions, and where each party's responsibility ends.
• Treat IT questions as design input. Every answer you prepare now is a delay you avoid later.

Why does IT so often become a late blocker?

IT usually hears about an AI agent through a request: create a service account, open access to a system, approve a new vendor. By then the business has often chosen a direction, told the team and set expectations. IT's questions arrive at the worst moment, and they feel like obstruction even though they are the questions that should have shaped the plan.

There is also a structural reason. IT carries the consequences of the project without having owned the decisions. They will be called when something stops working, they answer to auditors and customers about access, and they maintain the identity directory the agent will join. Being asked last while being held responsible is what turns a helpful function into a gatekeeper.

Involving IT early does not mean IT builds the agent or owns the project. The business owner owns the role and the outcome. IT owns the standards for identity, access, devices, logging and vendor risk. When those two responsibilities are separated clearly, each side knows what it decides. The checks that legal, IT and finance each run are covered in AI agent procurement: what legal, IT and finance each check, and it helps to know which of those belong to IT before the first conversation.

What should the first briefing to IT cover?

Bring a short written outline, even if parts of it are unknown. A page that says we have not decided this yet is more useful than a meeting that tries to improvise everything. The outline below is the minimum most IT teams need to form a view.

• The role: one sentence on the job the agent does, for whom, and what finished work looks like.
• The systems: every mailbox, drive, CRM, ticketing tool or database the agent will read from or write to, marked as read only or able to change things.
• The data: the categories involved (customer, employee, financial, contractual) and anything subject to regulation or contract.
• The channels: where people will talk to the agent, such as chat, email or a messaging app, and who is allowed to.
• The people: the business owner, the intended first users and the person who approves changes.
• The provider: who builds and operates the agent, where it runs, which model providers are involved and where support is delivered from.
• The boundaries: what the agent must never do, and which actions need a human approval first.
• The success criterion: how everyone will know it works, and what would cause a pause.

If you have drawn the setup as a diagram, bring it. A one-page view of the pieces, such as the one described in Draw Your AI Stack: A One-Page Architecture Map for Leaders, lets IT spot an unfamiliar connection in seconds instead of reading paragraphs.

Which accounts and access will the agent need?

This is the part of the briefing IT will care about most. The principle is simple: the agent should have its own identity, named for its function, owned by a named person, and limited to what its role requires. It should not run on a manager's login or a shared mailbox password. A separate identity gives you a clear audit trail, makes access easy to revoke and avoids the agent inheriting permissions that were meant for a person.

When the agent connects to tools that support delegated authorization, such as OAuth 2.0, it can be granted specific scopes through a token that IT can revoke without changing anyone's password. Where a tool only supports passwords or keys, say so, because that changes how the credential must be stored and rotated.

Bring a proposal for each of these decisions, and let IT adjust it:

• Identity: a dedicated account or service identity, with a named human owner.
• Scope: the smallest set of permissions that supports the role, starting with read access and adding write access only where a task needs it.
• Credentials: where secrets are stored, who can see them and how they are rotated.
• Connection method: revocable, scoped authorization in preference to shared passwords.
• Environment: whether a test environment or sample data exists, so the agent can be tried safely first.
• Expiry: a review date for every grant, and a procedure to remove access when the project ends or a user leaves.

These choices follow the usual authorization practices of least privilege and denying by default, which the OWASP authorization guidance describes well. For the recurring check after launch, see How to Run a Permission Review for Your AI Agents, Step by Step.

What security questions will IT ask?

Expect these questions, and prepare answers before the meeting. You do not need perfect answers. You need honest ones, plus a plan for the gaps.

• Where does company data go, and does the model provider store, log or retain it?
• Is any company data used to train models, and is that stated in writing?
• What happens if an email or document the agent reads contains hidden instructions?
• Which actions can the agent take that cannot be undone?
• Can we see everything the agent did, with the time, the requesting user and the system touched?
• How quickly can we cut off its access, and who is allowed to do it?
• Which subprocessors and locations are involved?
• How is the agent tested before a change reaches the people using it?

The instruction question deserves a real answer. Prompt injection is a known weakness of language-model applications, and the OWASP Top 10 for LLM Applications treats it as a core risk. The credible response is a design one, not a promise: limit what the agent can do after reading untrusted content, require human approval for high-impact actions and log what it did. If a provider says the risk does not exist, treat that as a warning.

If your company wants a shared vocabulary for these conversations, the NIST AI Risk Management Framework offers a structure for identifying and managing AI risks without requiring a large program. A lightweight start is described in AI Governance for Companies: A Lightweight Start for Mid-Sized Firms.

Where should support boundaries sit?

Support is where good projects quietly fail. Everyone assumes someone else will answer when an employee says the agent stopped replying. Settle it before launch by separating three kinds of support:

• Usage support: how to ask the agent for things, what it can and cannot do. Usually owned by the business owner or a trained champion.
• Agent support: the agent behaves oddly, a tool connection fails, an answer is wrong. Owned by whoever operates the agent, whether in-house or a provider.
• Infrastructure support: identity, network, devices, single sign-on and mailbox permissions. Owned by IT.

Then agree two further points. First, who can pause the agent immediately, and without asking permission first. Second, who is called first for each kind of problem, and how that person reaches the next one. A responsibility split between provider and company, written down, prevents the argument later. Shared Responsibility Model for AI Agents: Provider vs Company shows how to draw that line.

Illustrative scenario: an operations lead sets up an agent to draft replies from a shared support mailbox. IT learns about it after the fact and finds the agent running on a manager's login, with access to the manager's entire mailbox. The project pauses while accounts are rebuilt. Had the briefing come first, IT would have created a dedicated identity limited to drafting in that one mailbox, and the question of who to call when drafts stop appearing would already have an answer.

What is a practical sequence for briefing IT?

Use this sequence as a plan. It works whether the project is small or large, and it keeps IT's role clear.

• Write the one-page role summary and systems list before any meeting.
• Ask IT for a conversation, not an approval, so you hear constraints before you commit to a design.
• Walk through the briefing outline and record every open question with an owner and a due date.
• Agree the identity and access design, including a test environment or sample data.
• Agree the support boundaries and the procedure to pause the agent.
• Name one IT contact for the project, and set a review point before the agent reaches real users.
• Record what was agreed in the project documents, so it survives staff changes.
• Schedule a recurring access review after launch rather than relying on memory.

The same discipline applies at each stage of a pilot. Proof of Concept, Pilot or Production: What Each AI Stage Must Prove explains why the access and logging you accept in a proof of concept should not be carried unchanged into production.

How does a managed approach work with IT?

Be Human's first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. The IT-facing material comes out of that definition: a list of systems, the permissions requested for each tool, the actions that need human approval and the people who act when something goes wrong. Under managed operations, monitoring, integration maintenance, permission review and incident response are carried out remotely, in English or Portuguese, while the company keeps control of approvals and access. Changes to what the agent can reach go through the company's own approval process, so IT sees them before they take effect.

Frequently asked questions

Should IT approve the project or just be informed? Informing is not enough, because IT owns standards the project must meet. Give IT a real chance to set conditions on identity, access, logging and vendor risk, while the business owner keeps ownership of the role and its outcome. Approval should be about meeting those standards, not about the merits of the idea.

What if we do not have an IT department? Someone still fills the role, whether it is an outsourced administrator, an office manager or a founder who controls the accounts. Name that person, give them the same briefing outline and make sure they know who can revoke access. Skipping this step because there is no formal team is how agents end up on personal logins.

Can IT say no to an AI agent? IT can refuse a specific design, such as shared credentials or unlogged access, and that is healthy. A refusal early in the process usually points to a change that makes the project safer, like narrower scopes or a test environment. If IT blocks the whole idea, ask which conditions would change their answer and work from that list.

How much detail does IT need before the first meeting? One page is enough: the role, the systems, the data, the people and the boundaries. IT can ask for more once they see what is proposed. What matters is that the page is honest about what is still undecided.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.