Most "AI" tools are layered on top of identity as an afterthought. We invert that: the twin is a real principal in your IDM. Every action it takes is a normal Graph call from a normal user, logged under its name. The novel security work happens at the edges — tenant isolation, confirmation gates, threat model, exit ramp — and everything else inherits your existing posture.
Each customer gets a dedicated Linux container on peasyCloud. Encrypted token caches, audit logs, configuration and process memory are all isolated. There is no shared application database that touches customer credentials.
Every action is performed by a real principal — the twin — using your own Graph API. The action lands in your normal M365 audit log, exactly where your compliance team already looks. No second "AI activity" log to chase.
Every state-changing tool requires explicit "yes" from the human in the DM, against an exact action summary. The confirmation timestamp is bound to the action. This is a regulatory feature, not a UX nicety — it gives compliance a clear chain of custody.
Pick the orchestrator: Anthropic, OpenAI, OpenClaw, Hermes, or a model running locally. HIPAA / GDPR / SOC 2 customers run a model that never leaves the tenant boundary — same twin, same audit, no cloud LLM call.
The twin can only call tools in its catalog. There is no shell, no general-purpose code execution, no ability to escalate scope at runtime. If it isn't a registered tool, it can't happen.
Two app registrations per tenant: a narrow chat scope (read DMs, post messages as the twin) and an admin scope (only the Graph permissions needed for the tools you enable). You can revoke consent unilaterally at any time.
Every confirmed twin action produces one M365 Audit Log entry under the twin's UPN. We additionally write our own metadata record (requester, confirmation timestamp, conversation reference) that joins to the M365 entry by Operation ID, so a compliance reviewer can trace any change back to the human who asked for it.
{
"CreationTime": "2026-05-21T10:14:08Z",
"Id": "e3a1c8b7-…",
"Operation": "Assign license",
"OrganizationId": "yourco.onmicrosoft.com",
"UserId": "SamHelpDesk@yourco.com",
"ResultStatus": "Success",
"ObjectId": "sarah.lin@yourco.com",
"LicensesAssigned": ["ENTERPRISEPACK"],
"ClientIP": "<container egress IP>"
}
{
"AuditEntryId": "e3a1c8b7-…",
"RequestedBy": "doug@yourco.com",
"ConfirmedAt": "2026-05-21T10:14:05Z",
"ActionSummary": "Assign E3 to sarah.lin@yourco.com",
"ConversationRef": "teams://msg/19:meeting…",
"Orchestrator": "claude-opus-4-6",
"ToolName": "m365_license_assign"
}
Both records are queryable via the standard M365 audit search (for the first) and the
m365_audit_query tool or a direct API call (for the second).
The audit chain is identical regardless of how you got your twin. The fields below name the same actors whether you bought direct, run it yourself as an MSP, or get it through a Subtwin Partner.
| Field | Direct | DIY MSP | Subtwin Partner |
|---|---|---|---|
UserId (actor) |
The twin | The twin | The twin |
RequestedBy (human) |
The end user who DM'd the twin | The end user who DM'd the twin | The end user who DM'd the twin |
| Implementer (Subtwin metadata) | Subtwin | The MSP | The Subtwin Partner |
| Tenant of record (audit log location) | The customer's M365 tenant | The customer's M365 tenant | The customer's M365 tenant |
Key point: the audit log lives in the customer's M365 tenant in every path. The twin acts; the end user is the human who asked; the implementer is the operational party (Subtwin or an MSP). The customer's CISO reviews a single log — their own — with a single canonical actor naming.
We don't think security claims should be self-attested. Here's the evidence we provide on request — and what's still in progress, named honestly.
SOC 2 Type I letter available on request today. Type II audit underway; expected report Q4 2026. We'll share the bridge letter when it's signed.
Type II in progress
BAA available for healthcare customers running in local-LLM mode. We'll send our standard form on request and turn redlines around within five business days.
BAA available
EU-region peasyCloud deployments available today. DPA on file before any EU customer container is provisioned. We do not transfer customer data out of the chosen region.
EU residency available
Annual third-party pen test on the per-customer container build. Most recent report dated 2026-03; redacted summary available under NDA.
Annual · 2026
We publish the SBOM for the container build and ship signed images. Your security team can verify provenance against our signing key.
Published
Alignment underway against the ISO 27001:2022 control set. Full certification is on the v3 horizon; we'll not claim it until it's signed.
Planned
A breach of one customer's deployment exposes one customer's tokens — and nothing else.
One Linux container per customer. No shared application server. No multi-tenant request router that touches credentials.
Tokens, refresh tokens, app secrets and MCP credentials live inside the container, encrypted at rest with per-customer keys.
Your M365 audit log is the system of record. Our operational log is separate and never contains user PII from your tenant.
Outbound calls go to Microsoft Graph and the chosen LLM endpoint only. No third-party telemetry. Egress is auditable.
The twin authenticates as its own Entra user. We do not hold administrative credentials for anyone. You can rotate or disable at any time.
Tear-down is one operator command. Container destroyed, tokens revoked, the twin user disabled. See Exit ramp below.
We keep this list short on purpose. Changes are notified 30 days in advance.
Hosts the per-customer container. EU and US regions. Independent company; we are a customer of it. SOC 2 Type II.
Whoever you select — Anthropic, OpenAI, or none (local-only). You hold the contract; we don't proxy. In local mode, this row is empty.
Microsoft 365 / Entra / Graph is your environment, not our sub-processor. We act inside your tenant under credentials you control.
99.5% monthly target for twin availability. Status page at status.subtwin.com. Credits framework documented in the MSA.
Acknowledgement within 30 minutes, 24/7. Updates every 60 minutes until resolution. Direct line to an engineer, not a ticket portal.
If we believe customer data has been exposed, you'll hear within 24 hours of detection — well inside any regulatory window we know of.
Send a report to security@subtwin.com. We acknowledge in two business days and publish fixes in the SBOM.
Free products invite "what if they disappear?" — fair question. Here's the answer in writing.
One operator command tears down your container, revokes refresh tokens, and disables the twin user (you can keep it disabled or delete it from your IDM). We retain no customer data post-offboard. Provided in writing in the MSA.
Change-of-control clause in the MSA: existing customers get 90 days' notice and a free, no-questions migration window — including a source-available export of your container build.
We escrow the container build with a third-party software escrow service. In the event of a defined trigger, customers receive the source under a perpetual license to keep running.
Every action is already in your M365 audit log. Conversation context is configurable retention and stays in your container. Nothing of yours lives in our environment beyond operational logs without PII.
Teams DMs sent to the twin. Directory data the admin scope is consented to. Audit metadata the twin itself emits. Nothing else by default.
Short conversation context to maintain a coherent DM thread. Configurable retention. Local-LLM mode keeps everything inside the tenant boundary.
The user message and the tool-call response shape — never bulk directory dumps. In local-LLM mode, nothing leaves the tenant at all.
On offboarding, container and all derived state are destroyed. The twin identity remains in your IDM until you disable or delete it.
No. The twin authenticates as its own user, using OAuth tokens granted by your admin during onboarding. You can disable the twin user or revoke consent at any time and the twin loses access immediately.
Wherever you choose. We integrate over MCP, so any compliant orchestrator works. For HIPAA / GDPR / SOC 2 cases you can run a local model — the twin's reasoning then never leaves the tenant boundary.
Three layers — a narrow tool catalog, an explicit confirmation gate on every state-changing action, and the admin app registration's own Graph scope. See the product page for the full threat model.
It doesn't reach you. Containers are fully isolated, secrets are per-customer, audit logs are per-customer. The blast radius is one tenant by design.
Yes. We publish the SBOM, ship signed images, and will run a code-review session with your team on request. The twin stack is small enough to read end-to-end.
Production access is limited to two named on-call engineers with hardware-backed MFA. All container access is logged on our side and visible to you under audit obligations in the MSA. Customer data is never read except in response to a specific support request you've raised.
SBOM, architecture diagrams, threat model, sample audit entries, sub-processor list, SOC 2 Type I letter. Tell us a bit about your environment and we'll send the full set.