Built to be inspected.

Identity: named agents in the customer's tenant

Agents operate as named agent identities in the customer's own Microsoft Entra tenant (Microsoft Entra Agent ID). Every action appears in the customer's own audit logs, attributed to the specific agent that performed it.

• —The customer's Conditional Access policies apply to agents
• —Per-agent identities — no shared service accounts
• —Customer-controlled kill switch revokes all agent access at once

Credentials: brokered, never through the model

Credentials are brokered from Azure Key Vault at the moment of use. The AI model never sees a secret: prompts and completions contain no credentials by construction, not by policy.

• —Secrets stay in Azure Key Vault
• —Short-lived, scoped access per action
• —Every credential access is itself an audit event

Audit: append-only and tamper-evident

Every action, credential access, and approval lands in an append-only, hash-chained audit trail. Each entry references the hash of the previous one, so removal or alteration is detectable. An operator can answer "what happened on this ticket" without trusting anyone's memory.

Approvals: policy gates before risky actions

Every action class carries a policy: log, notify, or approve. Approval-gated actions pause until a human decides — delivered as interactive cards in Microsoft Teams. Per-customer tool blocking and spending caps bound what agents can do at all.

Data residency: Switzerland

All processing runs on Microsoft Azure Switzerland North. Swiss data residency by default, nDSG-aligned. Audit trails and case data stay in-region.

AI safety posture

We map our controls to Microsoft's taxonomy of agentic-AI failure modes: scoped tools and per-customer blocking against misuse of capability, approval gates against consequential mistakes, identity and credential brokering against privilege escalation, and the audit chain against silent failure.