Privacy
What AG MCP records, and what it does not.
AG MCP is operated by Allies Group Pte Ltd for its own staff. It is not offered to the public, and it does not sell, rent or share data with third parties for their own purposes.
How identity and permissions are applied
Every tool call is authenticated and attributed to the signed-in user. Business
Central, SharePoint, OneNote, Outlook and Azure DevOps operations use that user's
delegated rights. Ordinary analytical-warehouse reads use the restricted AZBOT
service identity behind AG MCP's access and sensitivity controls. Known raw
_gold and _bronze GL relations require Finance;
specifically configured super-users can use an explicit delegated Azure SQL path.
Any raw relation keeps the whole statement restricted. The CAC marketing view is
the shipped narrow curated exception; the general row-secured GL view remains
planned. System Teams posts require an active SQL-backed AG MCP administrator and
an exact configured destination, execute as AGBot, and attempt to audit the user
who triggered the post. Empty or malformed channel configuration denies every post.
Tool-specific restrictions can further narrow what a caller may retrieve or do.
What is recorded for tool calls
AG MCP attempts to write an operational record for authenticated tool calls,
including the diagnostic hello and agmcp_version tools.
Audit writes are best-effort, so a process or database interruption can leave a
gap rather than failing the business request.
| Recorded | Why |
|---|---|
| Your Entra object ID, user principal name and tenant in the tool-audit row | To attribute the request and apply your permissions |
| Your last-known display name in the separate identity record | To present and administer the caller identity |
| Timestamp, duration, tool name and outcome | Operation, troubleshooting and security review |
| Bounded, sanitized error type and detail when a tool fails | Troubleshooting without retaining URL credentials, query values, fragments or recognized secret patterns |
| The OAuth client identifier and a correlation identifier | To identify the calling client and correlate related diagnostics |
| Captured arguments, in redacted form, plus a one-way hash of the captured values before redaction | To understand what was asked, and to recognise repeated questions |
| A compact, redacted summary of what was returned, plus which SQL identity served a warehouse call when applicable | Diagnosing behaviour and verifying the warehouse identity boundary |
The query-hint match preview is a deliberate exception: its bounded SQL sample is processed in memory and omitted before generic tool-audit capture. The sample therefore does not appear in the stored arguments, argument hash, result summary or tool response.
For tool arguments, result summaries and persisted error details, redaction
removes credentials (tokens, bearer headers, API-key-like strings and
key=value secrets), e-mail addresses and telephone numbers. Error
sanitization also strips URL user information, query values and fragments. It
deliberately keeps ordinary business terms — search text, item and vendor
numbers, field values — because those are what make the record useful. Redaction
is pattern-based and is not guaranteed to catch every possible case.
HTTP request logs
Structured application logs emitted to App Service record every HTTP request, including failed sign-in attempts. They contain method, a fixed known-route label, a bounded query-shape summary, status, duration, correlation identifier and the caller UPN when authentication completed. Client IP addresses are not retained. Unknown paths collapse to one fixed label. Non-OAuth query values are never logged, and OAuth routes expose only a closed set of safe protocol values; all other values are replaced. Bodies and headers are excluded, and managed deployments disable Uvicorn's raw access log. Durable Azure Monitor ingestion admits only the reviewed structured fields and discards unclassified console lines before storage.
Where a page or dashboard reports its own call timings, AG MCP stores the artifact and per-tab session identifiers, refresh sequence, user identity, environment, start offset, tool name, duration, outcome, error code and row count. The telemetry report does not accept the business-tool arguments or results, but its free-text identifiers are only length-bounded; do not place sensitive content in them.
Other stored service state
AG MCP also stores encrypted refresh tokens and caller identity records; semantic mappings, mapping versions and clarification state; administrator-curated query hints and process recipes; one latest working-context checkpoint per user; and curation history. A checkpoint can contain the topic, facts, decisions, pending items and next step supplied by the client. Full source-system read results and the complete AI-client conversation are not stored as this service state.
Ordinary users can browse their own user-scoped mappings and their tenant's organisation mappings. Administrators can browse all mappings for curation. Team mappings remain hidden until team-membership resolution exists. Do not put secrets or sensitive personal information in mappings.
Retention policy
| Records | Kept for |
|---|---|
| Per-call operational records, including redacted arguments and result summaries | 5 years, matching Allies Group's data loss prevention policy |
| Page and dashboard telemetry, including user, artifact/session identifiers, tool, timing, outcome, error code and row count | 90 days |
| Structured application request, process, dependency-health and external availability telemetry in Azure Monitor | 30 days |
The two differ because they serve different purposes: the first is a business operation record, while the second is short-lived diagnostic information kept to investigate page performance and missing calls.
A record of who has used the service — name, account and when they were last seen — is kept for as long as the service operates.
No separate time-based retention period is currently published for refresh-token, semantic, curation, recipe, hint or working-context state. Those records follow their operational replacement, retirement or deletion lifecycle.
A database cleanup procedure implements these periods, but no automatic schedule currently calls it.
Credentials
AG MCP never receives your password. Sign-in happens at Microsoft. The refresh token Microsoft issues is held server-side, encrypted, so the service can continue acting for you without prompting on every request. Personal and AGBot Entra refresh tokens are stored by identity in the encrypted Azure SQL token store and are not exposed to MCP clients. Static service credentials such as AZBOT's are stored separately in Allies Group's Key Vault; derived access tokens are cached in server memory.
Where data goes
Records are stored in Allies Group's own Microsoft Azure subscription, within the Allies Microsoft 365 tenant.
Answers are returned to whichever approved AI assistant you connected. Claude, ChatGPT and Microsoft 365 Copilot are supported. Content sent to a connected assistant is handled under the agreement Allies Group holds with that provider, and is outside AG MCP's control once returned. Only connect AG MCP from an assistant and account your organisation permits for work data.
Access to the records
Tool-audit and HTTP-log access is intended for the Allies Group administrators who run the service. Semantic mappings follow the ownership and organisation rules described above. Artifact telemetry statistics are caller-only by default; an explicit cross-user UPN breakdown requires SQL-backed administrator authority and fails closed if that authority cannot be resolved. These records are used for troubleshooting, security review and understanding which capabilities are used. They are not used to evaluate individual performance.
Questions
Contact the Allies Group IT team.