Microsoft 365

Give a sandboxed agent governed access to Word, Excel, PowerPoint and Outlook, with no ability to send mail

The Microsoft 365 channel lets the agent work in the Word, Excel and PowerPoint files and the Outlook mailbox the user has open, without ever holding a Microsoft 365 password or token. It is off by default. Your policy lists which documents and which operations are allowed, and can require the user's approval. The agent can prepare an email draft, but it can never send mail.

How does it work?

The agent calls a fixed set of Office operations. Each call is checked against policy outside the sandbox, optionally approved by the user, recorded in the audit trail, and then carried out by the Vediram Levee add-in inside the user's own Office desktop apps.

Key properties:

• The agent never holds a Microsoft 365 credential. Operations run inside Office as the signed-in user.
• Operations act on documents and mailboxes the user already has open. The agent cannot open arbitrary files in Office on its own.
• Nothing sends mail. There is no send, reply-and-send, forward, delete, move or flag operation anywhere in the channel. The agent can create and edit a draft; a draft only becomes a message when the user clicks Send in Outlook.
• Default deny. No operation is permitted unless a policy rule allows it.
• Every refusal looks the same to the agent, so it cannot probe your policy.

Supported: desktop Word, Excel, PowerPoint and Outlook for Windows (Microsoft 365 Apps). Office on the web is not supported.

Which operations can the agent call?

Exactly 21 operations: reading and limited writing in Word, Excel and PowerPoint, and reading, searching and drafting in Outlook. The agent sees them as a tool server named levee_m365. There is no way for policy or the agent to add others.

Notes:

• Outlook search works on a fixed set of folders: inbox, sent_items, deleted_items, drafts.
• Recipients are set when a draft is opened and cannot be changed afterwards.
• PowerPoint write operations require a current Microsoft 365 Apps build (PowerPoint API 1.8 or later); on older builds they are refused.

Policy reference: proxies.m365

Each rule names an app, the documents it covers, the operations it allows, their limits, and whether the user must approve. Office rules live in the proxies.m365 section of the Levee policy, or in the Microsoft 365 section of a Portal policy.

{
  "proxies": {
    "m365": {
      "enabled": true,
      "rules": [
        {
          "id": "finance-models",
          "app": "excel",
          "files": ["C:\\Users\\*\\Documents\\Finance\\**\\*.xlsx"],
          "ops": ["read", "write"],
          "scopes": { "ranges": ["Inputs!A1:Z200", "Summary!A1:H50"], "max_write_cells": 5000 },
          "approval": "once"
        },
        {
          "id": "reports-read",
          "app": "word",
          "files": ["https://contoso.sharepoint.com/sites/reports/**"],
          "ops": ["read"]
        },
        {
          "id": "mail-assist",
          "app": "outlook",
          "ops": ["search", "read_message", "draft.open", "draft.update", "list_mailboxes", "list_calendar"],
          "scopes": {
            "allow_graph": true,
            "search_folders": ["inbox", "sent_items"],
            "max_results": 50,
            "draft_to": ["*@contoso.com"],
            "max_calendar_days": 90
          },
          "approval": "persist"
        }
      ]
    }
  }
}

Top-level keys

Rule keys

How rules are matched

The first matching rule decides, and a request outside its limits is refused. In detail:

• Rules are checked in order. The first rule whose app, op and file pattern match decides.
• If that rule's scope check fails (for example, the range is outside the allowed ranges), the operation is refused. Levee does not fall through to later rules.
• File patterns are case-insensitive. * matches within one folder level, ** matches across levels, ? matches one character. Paths are normalized before matching (slashes, . and .. segments, and SharePoint or OneDrive URL forms), so a request cannot sneak past a pattern with an alternative spelling of the same path.

Scopes

Write limits are fail-closed: a write rule without a size limit allows no writes, and a write larger than the limit is refused, never trimmed.

Approvals

You choose, per rule, whether the user is asked never, once, or every time.

The approval prompt shows the app, the target (document, folder, message or recipient set), the operation, the scope and the approval mode. For Outlook, approvals are tracked per folder, per message and per recipient set. See Approvals.

Built-in ceilings

Independently of policy, requests larger than these are refused: 1,000,000 characters of text or HTML, 100,000 cells, an 8,192-character formula, 1,000 search results, 256 recipients, a calendar span of about ten years, 100 bullet items in a slide body.

Formulas

Formula content written by excel.set_formula is not inspected. Some Excel functions (web queries, external links, real-time data) can reach the network from the user's Excel when the workbook recalculates. If that is not acceptable for a workbook, do not grant write on it, or keep approval on the rule so the user sees each change.

Cloud and on-premises mailboxes

Word, Excel and PowerPoint operations work the same everywhere. With an on-premises Exchange Server mailbox, the agent can only work on drafts. In detail:

For cloud mailboxes, the four Outlook read operations use Microsoft Graph with the user's own delegated, read-only permissions (Mail.Read, Calendars.Read, User.Read), obtained silently through the add-in. Mail.Send is never requested. If Microsoft Entra needs the user to sign in interactively, the operation is refused rather than showing a sign-in window; the user signs in to Outlook normally and retries. Graph calls honor the machine's proxy settings.

Only the signed-in user's own mailbox is available. Shared and delegated mailboxes are not.

For your IT team: deploying the add-in

Every user who uses this channel needs the Vediram Levee add-in in their Office apps. The Vediram Levee add-in is an Office task-pane add-in for Word, Excel and PowerPoint, and a mail add-in for Outlook. It has no credentials of its own and makes no policy decisions; it performs exactly the operation the host tells it to and reports the result. It cannot send, delete, move or flag mail, and it never saves documents on its own.

Choose the deployment method that matches your tenant:

For Exchange on-premises, a typical assignment looks like this:

New-App -OrganizationApp -FileData ([System.IO.File]::ReadAllBytes('C:\Deploy\levee-outlook.xml')) `
  -DefaultStateForUser Enabled -ProvidedTo SpecificUsers -UserList 'finance-team@contoso.com'

The add-in files are published with a SHA-256 integrity value in the Levee release notes, so you can verify what you host.

Allow Office to reach the local Levee service

Office runs add-ins in an isolated web view that, by default, cannot talk to services on the same machine. Run this once per machine, elevated, so the add-in can reach Levee on the local computer. No Group Policy or MDM setting grants this; the Levee installer runs it for you when the Microsoft 365 channel is installed, and you can run it yourself if it was removed:

CheckNetIsolation LoopbackExempt -a -n="microsoft.win32webviewhost_cw5n1h2txyewy"

Verify with:

CheckNetIsolation LoopbackExempt -s | Select-String 'win32webviewhost'

Task pane status messages

Open the Levee button on the Home ribbon (Word, Excel, PowerPoint) or in the message and compose ribbons (Outlook) to see the add-in status:

Each Outlook window (the reading pane and each compose window) runs its own copy of the add-in. Draft operations act on the compose window the draft belongs to.

What does the agent see when an operation is refused?

The same error every time. Every refusal, for any reason, returns the same tool error text:

m365/denied

The agent cannot tell whether policy refused the call, the document was not open, the user declined, the add-in was not connected, or the operation timed out. The real reason is in the audit trail.

Operations have a short deadline (a few seconds). A timed-out write may still have been applied in Office, so check the document before retrying.

Audit

Records contain hashes and counts, never document or email content. A typical record holds the operation name, a hash of its arguments, the sheet and range and cell count (or, for Outlook, the folder, the result limit, the number of recipients and the date span), the matching rule id, the outcome and the latency. A refusal records its reason category (bad arguments, policy, approval, audit, not available, dispatch, interaction required).

The Microsoft 365 channel writes its audit record before it carries out an operation; if the record cannot be stored, the operation is refused.

Limits inherent to the design

• The target document must be open in desktop Office, with the add-in loaded, before the agent can work on it.
• Only the operations in the table above exist. Macros, file open, save, share, delete and mail send are not part of the channel.
• On Exchange Server on-premises, Outlook access is limited to drafts.

Related

• How Levee Policy Works
• Approvals