Security and deployment
Built to run inside your rules.
How didii handles identity, permissions, data and AI. These are design commitments, not certifications.
Principles
Least authority
Agents reach only the tools a playbook allows.
Identity from your systems
Who the customer is comes from verified sessions, never from the model.
Real approvals
Tied to one action, one person, one time. A model saying 'approved' grants nothing.
Nothing done twice
Every action carries an operation ID and is reconciled before any retry.
Full audit trail
Checks, approvals, actions and messages are recorded against the case.
Data minimisation
Reads are scoped like actions: each step sees only the data it needs. Sensitive values stay out of logs.
Untrusted input stays data
Customer messages, documents and emails are treated as data. They cannot give the agent instructions.
Checked replies
Every reply is checked for accuracy, data leaks and promises your rules don't allow before it is sent.
An off switch
Any request type can be paused instantly, by you or by us. Usage is rate-limited.
Deployment
Where it runs.
- Available for evaluations
didii managed
For evaluations on synthetic or anonymised data. The fastest way to see the agent on your request types.
- Planned
Your cloud
Deployed into your own cloud account or private network, under your security controls and monitoring.
- Planned
In-country
In an approved jurisdiction or on your premises, including model processing where required.
Your data
Your data, your jurisdiction.
- No real customer data before a written agreement on handling, access and retention.
- Model providers are replaceable. Any provider or model change needs your approval and evaluation first.
- An isolated environment for each institution, with access controls verified before real data enters.
- No training of shared models on your data.
Controls and rollout
Authority grows with evidence.
An agent earns each level separately for each request type. Moving up a stage is your decision.
| Stage | What the agent may do | Production writes |
|---|---|---|
| Synthetic | Full demonstrations against simulated systems and fictional data | None |
| Historical shadow | Works approved past cases; results measured against what staff did | None |
| Staff assist | Retrieves approved live context and prepares recommendations | Staff decide |
| Restricted execution | Executes only individually approved actions under your rules | Approved actions only |
Release-blocking failures: unauthorised action, disclosure across customers, closing a case without verified evidence.
Responsible AI
What the model may and may not do.
The model may
- Interpret what the customer is asking, in their own words
- Ask for missing information
- Propose the next step in a playbook
- Draft messages within approved wording
- Summarise a case for staff
The model may not
- Decide who the customer is
- Grant itself permission or approval
- Call a system outside its playbook
- Report an outcome the system has not confirmed
- Move customer money
- Pretend to be a person, or refuse a request for one