Microsoft data access

What we read

• Your email address and display name from your Microsoft account.
• The Microsoft account ID Supabase Auth uses to keep your sign-in linked.
• We always show the Microsoft account picker (prompt: select_account) — we never silently reuse a session.

What we write

• A row in our profiles table with your email and full name. That's it.

What we never access

• No Microsoft Graph API calls.
• No mailbox, calendar, files, contacts, or directory data.
• Nothing tenant-wide.

Why we need it

So you can sign in without a separate password. Optional — email/password sign-in is also supported.

Where it's stored

profiles table on Fronterio's Supabase database (Frankfurt, EU). Row-level security ensures you can only read your own profile.

What we read

• Exactly one Microsoft Graph endpoint: /v1.0/reports/getMicrosoft365CopilotUsageUserDetail(period='D30').
• This returns a CSV of Copilot usage counts per user per app (Word, Excel, PowerPoint, Teams, Outlook, OneNote) over the last 30 days.
• Plus User Principal Name (UPN), department, and last activity date. We also use User.Read.All to resolve department metadata.

What we write

• Nothing. This integration is read-only against Microsoft Graph.

What we never access

• No file content. No message content. No calendar events. No chat transcripts.
• No Copilot prompts and no Copilot responses.
• The report API exposes only counts of actions per app — never the action itself.

Why we need it

To show you “70% of Marketing uses Copilot in Word at least weekly; Engineering hasn't started” without you having to build the dashboard yourself.

Where it's stored

ai_tool_usage_data on the Fronterio side. The User Principal Name is never stored in plaintext — it is hashed to ms_<sha256(orgUUID + upn)> before it touches the database. The salt is your organisation's UUID, random and per-org. We cannot reverse-look-up which user a hash belongs to without knowing the original UPN, and two organisations with the same employee produce different hashes (no cross-tenant correlation). Refresh tokens are stored encrypted at rest. Disconnecting via Settings or revoking admin consent invalidates the refresh token.

What we read

• The site you point us at, to verify it exists and to discover whether the lists and libraries we need already exist.
• That's the entire read surface.

What we write

• A fixed, known set of artefacts that Fronterio creates and owns:
• Lists: “AI Use Cases”, “AI Agents”, “Compliance Status”, “Guide Completions”.
• Document libraries: “AI Reports”, “AI Playbooks”.
• Items inside those: rows for use cases, agents, EU AI Act obligations, guide completions; PDFs of assessment reports; HTML playbooks; weekly audit-digest PDFs.

What we never access

• No existing SharePoint files.
• No site analytics. No SharePoint search. No user permissions.
• We do not enumerate, read, or modify any list, library, or file we did not create.
• The granted permission (Sites.ReadWrite.All) is broader than what we use — Microsoft does not offer a tighter scope today — and Fronterio's code only ever calls a fixed set of endpoints.

Why we need it

Customers want their intranet to be the canonical record of “what AI we use”. This is the clean way to keep SharePoint and Fronterio in sync.

Where it's stored

Connection metadata (tenant ID, site URL, site ID, encrypted client credentials, sync configuration) lives in intranet_connections. Every sync write is logged in intranet_sync_log so you can audit what we sent and when.

What we read

• Only messages addressed to the Fronterio bot — direct messages, @Fronterio mentions in a channel, or replies in a Fronterio-initiated thread.
• For each such message: text, sender Azure AD object ID, sender User Principal Name, tenant ID, channel ID, conversation ID.
• Every inbound activity is JWT-validated against Microsoft's Bot Framework public keys before we even parse it.

What we write

• Replies and proactive notifications — text or Adaptive Cards — back to the same conversation.

What we never access

• No messages that aren't directed at the bot.
• No chat history. No team membership. No files in Teams. No user presence. No calendar.
• We never crawl a channel; we only see what is sent to us. The Teams platform itself enforces this.

Why we need it

So employees can ask Fronterio questions without leaving Teams, and so Fronterio can deliver tip-of-the-day, prompts, and learning content where people work.

Where it's stored

teams_user_mappings caches the Azure AD object ID ↔ Fronterio user link — only owners, admins, and AI Leads in your org can read it (RLS-enforced). teams_conversation_references stores the minimum needed to send proactive replies (service URL, conversation ID, channel ID). We do not store message bodies.

What we read

• Power Platform BAP API — to enumerate Power Platform environments your service principal can see.
• Copilot Studio REST API — to list bots in those environments and read metadata (display name, description, environment ID, solution ID, publish status, last published date).
• Microsoft Graph (Teams app catalog) — only the /v1.0/appCatalogs/teamsApps endpoint, filtered to apps distributed inside your organisation.

What we write

• Only when you explicitly choose to deploy a Fronterio-governed agent: we create or update a bot definition (display name, description, instructions, capabilities, guardrails). When you click “Retire”, we delete it.

What we never access

• No conversation transcripts. Microsoft exposes Copilot Studio transcripts via a Dataverse table; Fronterio's code does not query that surface.
• No Power Platform data. No Dataverse rows beyond what's needed to identify a bot. No flows, no canvas apps.

Why we need it

“What Copilot Studio agents do we have, and which are governed?” is the most-asked Enterprise governance question. This integration answers it without anyone manually maintaining a spreadsheet.

Where it's stored

Discovered bot metadata in copilot_studio_agents. Lifecycle changes in copilot_studio_lifecycle_events. Aggregated usage telemetry (sessions, users, actions, escalations — counts only, no content) in copilot_studio_telemetry. All RLS-scoped to your organisation.

What we read

• This rides on the Teams agent (§4) — same Azure Bot registration, same scopes, same data flow.

What we write

• Same as the Teams agent: replies and proactive messages.

What we never access

• There is no separate Microsoft permission to grant. If you've reviewed the Teams agent above, you've reviewed this.

Why we need it

So Fronterio is reachable from the Microsoft 365 Copilot Chat surface as well as Teams, without doubling the bot footprint.

Where it's stored

Same backend as the Teams agent. Manifest version 1.21 declares copilotAgents.customEngineAgents pointing at the same bot ID.

What we read

• An opaque marketplace token Microsoft sends when you click “Activate” after purchase.
• We exchange it via the SaaS Fulfilment API for: subscription ID, plan ID, quantity, operation ID.
• Marketplace-initiated webhooks (Suspend, Reinstate, Unsubscribe, ChangePlan, ChangeQuantity, Renew) signed by Microsoft as JWTs.

What we write

• Nothing into your tenant. We create a Fronterio organisation linked to your marketplace subscription ID and acknowledge each webhook back to Microsoft.

What we never access

• No customer Azure AD identity. The marketplace token is opaque — it does not expose user identity.
• We do not call any Graph endpoint and we do not have any token that would let us.
• The fulfilment API authenticates with Fronterio's own AAD app, not yours; the only thing we know about your tenant is the tenant ID embedded in the webhook JWT.

Why we need it

Microsoft Commercial Marketplace is the third billing channel alongside Stripe direct and reseller. It exists so customers can transact through their existing Microsoft commerce relationship.

Where it's stored

Subscription identifiers on the organizations row. Webhook events idempotently recorded in processed_marketplace_events. Both system-admin-only.

What we read

• The Azure REST API at https://management.azure.com.
• We list subscriptions only to validate that the service principal works (one call: GET /subscriptions).
• We read provisioning state on agent resources we created.
• We read Azure Monitor metrics — counts of Requests, SuccessfulRequests, FailedRequests — for the agents Fronterio deployed.

What we write

• We create, update, and delete agent resources at the Microsoft.MachineLearningServices/workspaces/{ws}/agents/{name} path.
• Each agent is tagged with fronterio:agent-id, fronterio:risk-level, fronterio:autonomy, and managed_by for traceability.

What we never access

• No Azure RBAC policies.
• No subscription-wide reads beyond the one validation call.
• No other resource groups.
• No private endpoints, networking, or virtual networks. No Azure AD. No data plane (we don't read what an agent processes).

Why we need it

So Fronterio governance enforcement (guardrails, risk classification, content safety) is reflected in the actual Azure resource and audited by Azure Monitor — not just promised by Fronterio.

Where it's stored

Encrypted service principal credentials in deployment_credentials. Deployment records in agent_deployments with the platform-native config snapshot.