Most "AI" tools are an afterthought layered on top of identity. aidizen flips that: the Aid is an identity — a first-class citizen in your enterprise — and every action it takes lands in your own audit log under its own name. The security model isn't a feature; it's the foundation the rest of the product sits on.
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 touching customer credentials.
Every action is performed by a real principal — the Aid identity — 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. The confirmation is logged with 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 / SOC2 customers run a model that never leaves the tenant boundary — same Aid, same audit, no cloud LLM call.
The Aid 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 Aid) and an admin scope (only the Graph permissions needed for the tools you enable). Capabilities can be revoked unilaterally by the customer at any time.
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. Per-customer keys.
The customer's M365 audit log is the system of record. We keep an operational log on our side for support; it never contains user PII.
Outbound calls go to Microsoft Graph and the chosen LLM endpoint only. No third-party telemetry. Egress is auditable.
The Aid authenticates as its own Entra user. We do not hold administrative credentials for anyone. Customers can rotate or disable at any time.
Tear-down is one operator command. Container destroyed, tokens revoked, Aid identity disabled. We retain no customer data post-offboard.
Most of the security story is "the customer's existing compliance regime already covers this." The Aid is a user in their tenant; the audit log is theirs; the LLM (in local mode) never leaves the boundary. We close the gaps with a posture aligned to common frameworks.
Teams DMs sent to the Aid identity. Directory data the admin scope is consented to. Audit metadata the Aid 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 Aid identity remains in the customer's IDM until the customer disables it.
No. The Aid authenticates as its own user, using OAuth tokens granted by your admin during onboarding. You can disable the Aid identity or revoke consent at any time and the Aid loses access immediately.
Wherever you choose. We integrate over MCP, so any compliant orchestrator works. For HIPAA / GDPR / SOC2 cases you can run a local model — the Aid's reasoning then never leaves the tenant boundary.
Three layers: a narrow tool catalog (it cannot call anything outside it), an explicit confirmation gate on every state-changing action, and the admin app registration's own scope (Graph won't let it do things the scope doesn't cover).
It looks like any other audit entry in M365 — the actor is the Aid identity, the action is the Graph operation, and the target is the affected object. We additionally tag the entry with the requesting user and confirmation timestamp via Graph's on-behalf-of claims and our own metadata.
It doesn't reach you. Containers are fully isolated, secrets are per-customer, audit logs are per-customer. The blast radius is one tenant. We've designed for "any one tenant is breachable in theory" — and made sure that's the worst case.
Yes. We publish the SBOM, ship signed images, and will run a code review session with your team on request. The Aid stack is small enough to read end-to-end.
SBOM, architecture diagrams, threat model, sample audit entries. Tell us a bit about your environment and we'll send the full set.