What should an AI IT approval brief include?

It should include the workflow, systems, access level, data boundaries, action boundaries, controls, owners and review path.

Should an AI assistant bypass two-factor authentication?

No. Authentication and consent should be part of the approved access model, with least-privilege permissions and visible administration.

How to Get IT Approval for AI Outlook Access

AI projects stall when IT is asked to approve a vague idea. They move when IT is given a narrow access request, clear controls and a way to see who remains accountable.

That was the live buying signal in this week's client question log. The champion wanted to proceed, but Outlook and calendar access sat with an external IT provider. Without that access, the useful work could not reach the daily briefing, follow-up and appraisal-to-proposal workflow the business actually wanted.

The lesson is simple: treat IT approval as part of the product, not as paperwork after the sale.

Why does IT approval become the blocker?

IT approval becomes the blocker because AI automation asks for access to the systems that already carry client context. In many service businesses that means Outlook, calendar, CRM, project tools and shared documents.

From IT's view, the risk is not the word AI. The risk is unclear access. Can the assistant read every mailbox or only a narrow calendar scope? Can it send external emails or only draft internal updates? Can it see bank details, accounting records or sensitive client data? Who reviews the output before anything leaves the business?

A three part IT approval packet showing access request, controls and review path. — An IT approval packet should show what the system needs, how it is controlled and who reviews the output.

Tip

If IT has to infer the risk from a sales proposal, the request is already too broad. Give them the access, controls and review path in plain English.

What should the IT brief include?

A useful IT brief should be short enough to forward, but specific enough for a technical reviewer to assess. It should name the workflow, the systems involved, the access requested and the controls around the action.

For an Outlook or calendar-connected AI assistant, include these points:

Purpose: the exact task the assistant supports, such as daily briefing, follow-up extraction, internal task creation or appraisal-to-proposal preparation.
Systems: the specific systems involved, such as Microsoft Outlook, calendar, Reapit, Monday.com or WhatsApp.
Access level: whether the assistant needs read-only access, draft-only output or permission to update records.
Data boundaries: what it must not access, such as bank details, accounting data, identity documents or unrelated mailboxes.
Action boundaries: whether the assistant can contact only internal staff, draft messages for review or send anything externally.
Controls: multi-factor authentication, least-privilege permissions, logging, named owners and human approval for sensitive steps.

How do bots handle two-factor authentication?

Two-factor authentication is not something to work around. It is part of the control model. In Microsoft environments, the practical question is usually whether the assistant uses delegated access on behalf of a signed-in user or application access granted by an administrator.

Microsoft describes delegated permissions as access on behalf of a signed-in user, and application permissions as access without a signed-in user. It also warns that applications should only request the permissions they need. That principle matters more than the specific connector.

For a non-technical buyer, the safe translation is this: the assistant should not borrow one person's password and sneak through the side door. It should be approved as a controlled application, scoped to the minimum useful access and visible to the people responsible for the systems.

Three access lanes for an AI assistant: read only, draft only and send or update. — Separate read-only, draft-only and action permissions before IT reviews the request.

How do we stop AI from emailing the wrong people?

The safest early design is to restrict communication to internal employees and keep a person in the approval loop. If the assistant drafts a message, a human sends it. If it creates a task, a human can inspect the source. If it finds missing information, it routes the exception instead of guessing.

An allowlist is a practical starting point. It defines who the assistant may notify, which channels are allowed and what kinds of message require approval. This matters when a prospect or client worries that bots could email customers, suppliers or external parties without context.

What should be approved before the first build?

Before the first build, approve the access boundary, the first workflow and the review rule. Do not ask IT to approve an all-encompassing future system. Ask them to approve one controlled loop.

A good first approval packet says: this is the workflow; these are the systems; this is what the assistant can read; this is what it can create; this is what it cannot do; this is who reviews exceptions.

This is the same operating discipline behind AI CRM integration: connect context into the record people already use, but keep judgement visible.

How Catalyst approaches IT approval

Catalyst Systems designs AI workflows around the business burden and the approval path at the same time. The system should remember what matters, but it should also make the risk visible enough for IT, the champion and the decision-maker to assess.

If Outlook, calendar or CRM access is the blocker in your AI project, book a Sprint conversation. We will help you turn the vague access question into a practical first workflow, an approval packet and a controlled starting point.