Identity & Trust

Your audit log already knows how to read us.

Most AI tools treat identity as an afterthought. We invert that: the twin is its own real, licensed user in your directory — not a shared service account and not an opaque bot. It works two ways, both fully attributed. Working agentically, it accepts requests under its own delegated authority — from people or systems, on the surfaces you enable. Acting on a person’s behalf, it performs the action for a specific requester — recorded against that person and scoped to what they are permitted — while execution stays the twin’s attributable principal. No identity takeover, no credential sharing.

One container per customer

Dedicated isolated container. Encrypted token caches, audit logs, configuration and process memory are isolated. No shared application database holds customer credentials.

Audit in your own log

Every action is performed by a real principal — the twin — via your own APIs. Entries land where your compliance team already looks. No second “AI activity” silo.

Explicit confirmation gate

Destructive and high-stakes actions require an explicit "yes" against an exact action summary, bound to the requester. Confirmation timestamp is on the chain of custody.

Private, isolated inference

Choose where reasoning runs. Managed path for most teams; private, isolated inference inside your boundary for residency, regulated workloads, or policy that requires it. Same twin, same audit, same controls either way.

Narrow action surface

Only registered actions. No shell, no general-purpose code execution, no runtime scope escalation. If it isn’t catalogued, it can’t happen.

Least-privilege, separately consented

Narrow request-surface access plus admin scopes for the platforms you enable. Microsoft 365, Google Workspace, Azure, and GCP each get their own grants. L2 planes stay inert until consented. You can revoke any plane unilaterally.

JIT elevation, no standing infra admin L2 rolling out

Escalation writes elevate the twin’s own identity time-bound through just-in-time elevation, then drop. Same confirmation gate as L1 directory writes.

Never a login as a person

No credential borrow. No “act as me.” Dual attribution: twin principal + human requester. That is the non-negotiable boundary for Corporate IT.

Dual attribution

Two identities on every action.

Compliance can answer: who performed it (the twin), who requested it (the human), and when they confirmed.

Human requesterPolicy-scoped rights
Twin principale.g. avery@yourco.com
Customer audit logBoth identities + confirm
# Conceptual audit row
actor:          avery@yourco.com
requested_by:   doug@yourco.com
confirmed_at:   2026-05-21T10:14:05Z
operation:      license.assign
subject:        sarah.lin@yourco.com
result:         success
Threat model (summary)

What we design against.

Prompt injection / social engineering

Requester identity is taken from the authenticated ingress channel, never from free-form body text alone. Allow/block lists and tier checks on the action path. Confirmation bound to the original requester when multiple parties share a thread.

Cross-tenant bleed

One container per customer. Request-surface credentials and admin powers are separated so a compromised ingress path does not grant admin powers.

Over-privileged automation

High-risk group guards, directory-role guards, multi-party destructive lockdowns, JIT only for elevated writes, no standing cloud admin.

Full threat model and controls: contact security@subtwin.com for a security pack.

Security review? We’ll walk the model.

Sample audit rows, consent shapes, and isolation diagram — ready for CISO review.