microsoft365 v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-msgraph-app-credential

Custody

customer_vault

Injection

header (Authorization)

The value stored under this reference is the complete Authorization header value (scheme included): 'Bearer ' followed by an OAuth2 access token for Microsoft Graph, minted with the client credentials flow from the client's own app registration against login.microsoftonline.com — POST /{tenant}/oauth2/v2.0/token with scope https://graph.microsoft.com/.default — and placed in the client's own secret manager by an external deployment process. This grant issues no refresh token, so there is no refresh path to review: renewal ownership sits with the external process, which obtains a replacement access token before the current one expires (access tokens last about an hour) and stores the new complete header value. The stored value is never the client secret or certificate assertion material — those stay with the external token process, and a certificate credential is preferable to a client secret for the app registration. Tokens can be revoked by rolling or removing the app registration's credentials; an expired or revoked value fails closed. With client credentials there is no signed-in user, so the token carries application permissions: consent only the minimum set that makes these capabilities work, and weigh before consenting that Mail.Send as an application permission lets the app send mail as any user in the tenant. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack. The Teams channel capability uses a different reference with a delegated-token contract — see the pack notes.

• m365-directory (api, pii): https://graph.microsoft.com/v1.0/users
• m365-mailbox (mailbox, pii): https://graph.microsoft.com/v1.0/users/USER_ID
• teams-channel (channel, pii): https://graph.microsoft.com/v1.0/teams/TEAM_ID/channels/CHANNEL_ID

USER_ID (a user id or userPrincipalName), TEAM_ID and CHANNEL_ID in the endpoint paths are placeholders: the deployment must substitute the concrete user, team and channel each capability is bound to before enabling the pack, and the pack must not be enabled with the literals in place — the review does not rely on Microsoft Graph rejecting literal placeholder identifiers as the control. The egress allowlist stays graph.microsoft.com, a real shared API host, not a placeholder. Use an app registration whose Microsoft Graph permissions cover only what these capabilities need; the pack does not create one. The pack registers endpoints; the deployment chooses scopes, and the application-permission vs delegated-permission distinction is the deployment's decision: application permissions (User.Read.All, Mail.Read, Mail.Send, Calendars.ReadWrite) are tenant-wide daemon-grade power consented by an admin, while delegated permissions act as one signed-in user within that user's own access. microsoft365.teams.channel_message.send carries its own credential reference, secret-ref-msgraph-delegated-token, and the contract is deliberately different from the pack-level reference: Microsoft documents application permissions for posting a channel message only in the migration flow (Teamwork.Migrate.All, against a channel in migration mode), while ordinary channel posting requires the delegated ChannelMessage.Send permission. The stored value under the Teams reference is therefore a delegated Graph access token obtained and renewed by an external process (delegated flows can issue refresh tokens, and that external process owns the refresh) as the complete 'Bearer <token>' header value; the pack-level client-credentials credential cannot perform ordinary channel posting, the migration scenario is not registered by this pack, and the two references are not interchangeable. sendMail and the Teams post both carry the send action at the R3 floor, and send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer): a message that has left cannot be un-sent. Calendar event creation declares create and send at the R3 floor: Microsoft documents that creating an event that includes attendees sends invitations to all attendees, dispatched by the server, and that this cannot be configured — so the unrestricted operation carries the send verb, not a reviewer warning; a create-only R2 variant would require an actually enforced restriction excluding invitation dispatch, which this pack does not register. This pack registers only Microsoft Graph v1.0 endpoints: nothing from the beta endpoint, and no $batch, change notifications or subscriptions, delta queries, OneDrive or SharePoint drives, Teams chats (as opposed to channels), or mail, calendar or Teams update and delete operations — documented exclusions, not approximated capabilities. This pack complements rather than duplicates Microsoft Agent 365's own controls: Agent 365 governs agents on Microsoft's agent platform, while AAES governs any agent calling Microsoft Graph here regardless of which agent platform it runs on. AAES has not been certified by Microsoft; the endpoints here are a reviewable default, not a vendor guarantee.

Review completed: 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://learn.microsoft.com/en-us/graph/api/user-list?view=graph-rest-1.0 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/graph/api/user-list-messages?view=graph-rest-1.0 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/graph/api/user-list-events?view=graph-rest-1.0 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-1.0 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/graph/api/channel-post-messages?view=graph-rest-1.0 (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant-flow (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.