Identity
Know who is behind every action.
Every request is linked to a verified user and an active organisation membership. External groups and roles never become Zeronetic permissions.
- Microsoft Entra ID
- Google Workspace and Okta
- OIDC and SAML
Zero trust permissions & data governance
AI can only see
what you can see.
Do what you can do.
AI should never have more authority than the person it represents. Every assistant request is checked against the initiating user’s access, the assistant’s capabilities and organisational policy — before anything executes.
- User permissions govern AI access
- Your data, your authority
- Every action attributable and auditable
tool call
outlook.listMessages - Identity Session verified
- User permissions Mail.Read granted
- Assistant capability Mail.Read allowed
- Policy finance.inbox → allow
- Approval Not required
- Execution Completed in 284 ms
ALLOW Audit entry written · correlation 7f3a…
fail-closed user authority enforced decision recorded
How it works
AI operates within your authority.
An assistant is a tool of the person using it, not an independent identity. Every request respects the initiating user's permissions, the assistant's granted capabilities and the rules your organisation sets.
- 01
Establish who is acting
User identityEvery request is tied to a verified person and an active organisation membership. Zeronetic verifies both before evaluating anything.
- 02
Establish what they can access
User permissionsThe initiating user's permissions decide what the AI can see and do. It cannot reach information or actions beyond that person's authority.
- 03
Check assistant capabilities
Explicit AI permissionsEach assistant holds only the capabilities explicitly granted to it. Its available actions are limited by its own grants and by the user's permissions.
- 04
Apply organisational policy
Policy enforcementEvery request is evaluated against organisational rules. The outcome is allow, deny or require approval.
- 05
Obtain approval when required
Human oversightSensitive actions can require an authorised approver. Approvals are attributable to the request, and every permission and policy is checked again before execution.
- 06
Execute with accountability
User-scoped executionActions run through the gateway on the requesting user's own connection. The external system still enforces that user's access, and the outcome is recorded.
audit
Every decision and outcome records the initiating user, the permissions applied, the policy version and the correlation ID — so every AI action has an accountable owner.
Capabilities
Control what AI can access. Govern what it can do.
User permissions, assistant capabilities, policy, approvals and audit evidence in one enforcement layer.
20 permissions in the default catalog
6 checks before any execution
-
User-based permissions
AI inherits no independent authority. Every request is constrained by the permissions of the person it represents — explicit grants only, no implicit privileges.
-
Explicit assistant capabilities
You decide which actions each assistant may attempt. Access to a tool never implies permission to use it, and new assistants start with nothing.
-
Organisational policy
One policy layer for every AI request. Requests are allowed, denied or held for approval — deny overrides allow, and a failed evaluation blocks execution.
-
Deny by default
Nothing is permitted implicitly. A missing user grant, missing assistant capability or failed policy evaluation stops the request before it can execute.
-
User-scoped execution
Assistants act through the requesting user's own OAuth connection. No shared administrator accounts, and the external system's permissions still apply.
-
Human approvals
Sensitive decisions can require an authorised person. Approvals are attributable to the request, and every check runs again before execution.
-
Audit and evidence
Every decision records who initiated it, the permissions applied, the policy outcome, the approver where relevant and the execution result — with correlation IDs and policy versions.
-
Secure credentials
Provider credentials live in AWS Secrets Manager and OAuth tokens are KMS-encrypted. Credentials are never exposed to AI models.
Security model
Authority is never assumed. Every action is checked.
AI should not be trusted with more authority than the person it represents. These are the boundaries that hold even when application code or an integration fails.
Permissions
The user defines the boundaries.
Permissions live in Zeronetic and are read per request. The assistant's token is never treated as authority, and a missing grant is a denial.
- Per-request permission checks
- Explicit user grants
- No implicit authority
Policy
Additional controls only restrict authority.
Every request must satisfy user permissions, assistant capabilities and organisational policy. Required approvals are recorded, attributable and revalidated before execution.
- Deny overrides allow
- Approval never bypasses checks
- Failed evaluation blocks execution
Evidence
Every decision has an accountable history.
Security decisions and execution outcomes are recorded separately from telemetry, with the initiating user, the approver and the policy version that applied.
- Append-only audit log
- Initiator and approver attribution
- Correlation IDs and policy versions
- AI cannot see more than the user can see
- AI cannot do more than the user can do
- No implicit permissions
- No policy means no permission
- Deny overrides allow
- Failed evaluation means no execution
- Approval does not bypass security
- Every action is attributable
Data sovereignty
Your data. Your permissions. Your control.
Business data should stay inside the boundaries your organisation sets — not the unrestricted reach of an AI assistant. Zeronetic keeps AI access grounded in the identity and permissions of the person using it.
01
Access what the user can access
Assistants use the requesting user’s own connected account. If a person cannot open a mailbox, document or site, their assistant cannot reach it either.
02
No privileged AI accounts
Integration calls use individual user connections instead of shared administrator accounts. Connecting a system does not give AI blanket access to it.
03
Your organisation controls authority
User permissions, assistant capabilities and organisational policy decide what can be accessed and which actions can be performed.
04
Keep control of your data
Data access stays tied to your identity, permissions and governance boundaries. Zeronetic adds one enforcement point without handing AI unrestricted access.
AI should never see more, or do more, than the person it represents is authorised to do.
Integrations
Connect your systems. Keep your access boundaries.
Bring AI into the systems your workforce already uses without giving it unrestricted access. Every connected action is governed through the requesting user's identity and permissions.
Business systems
Start with the tools your people already use.
Microsoft 365 first: Outlook, SharePoint and OneDrive run through the requesting user's own connection, so access stays tied to their existing permissions. The same enforcement model extends to Slack, Xero and HubSpot.
- Outlook (first connector)
- SharePoint (first connector)
- OneDrive (first connector)
- Slack (planned)
- Xero (planned)
- HubSpot (planned)
Identity providers
Bring your existing identity infrastructure.
Your identity provider establishes who the user is. Zeronetic determines what AI may do on their behalf.
- Microsoft Entra ID
- Google Workspace
- Okta
- Generic OIDC
- SAML 2.0
first connectors planned
Private preview
Give AI the ability to act, without giving it your authority.
Your people should be able to use AI across business systems without losing control of their data, permissions or accountability. We're onboarding a small group of organisations to explore how Zeronetic governs AI access to real systems.
No marketing lists · one email when your invite is ready