Security Overview
Demiton is built on a single governing principle: your connected systems define access; Demiton enforces it. Every operation is identity-bound, every decision is auditable, and no action executes without a traceable identity.
How does Demiton enforce identity-bound execution?
Every operation in Demiton - AI queries, workflow runs, data retrievals, writes to connected systems - is attributed to the user or system identity that initiated it. If identity cannot be determined, execution stops.
This means:
- API requests are authenticated via your API key, which carries your organisation’s identity context
- MCP tool calls are bound to the user identity that established the session
- Automated workflows record the identity that triggered them - human or system
- No operation is anonymous
How does Demiton determine what data a user can access?
Demiton does not maintain its own role-to-data mapping. Access to data in your connected systems is derived from the authoritative systems you already use:
| What you want access to | Authority |
|---|---|
| Financial data (budgets, actuals, ledger) | Your ERP (Business Central, Finance & Operations) |
| Project allocation and operational scope | Your field management system (Assignar) |
| Payroll records | Your payroll system (KeyPay) |
| Documents and files | Your document management system (SharePoint, Dropbox) |
| Identity and organisational attributes | Microsoft Entra ID |
When a user queries Demiton - through Studio, the MCP server, or a workflow - Demiton resolves that user’s access against each relevant authority and filters results accordingly. A user who cannot see a project’s financial data in Business Central will not see it in Demiton.
Zero-trust default
If access cannot be positively confirmed, access is denied. An unavailable system authority, a missing identity binding, or an unresolvable permission - all fail closed. Users see a clear error rather than partial or incorrect data.
What are the three data domains?
Demiton recognises three data domains, each with a distinct access profile:
| Domain | What it covers | Default access |
|---|---|---|
| Operations | Site diaries, forms, allocations, schedules, equipment | Broad - visible within your functional team and region |
| Financials | Project budgets, actuals, variance, purchase orders, progress claims | Project-scoped - derived from your allocation or ERP permission sets |
| Payroll | Pay records, individual hours, cost rates, workforce costs | Restricted - payroll administrators, executives, and self-service for own data |
Project Managers see aggregated labour costs for their projects (financials domain) but not individual pay rates or records. Payroll data is never surfaced to general users regardless of what question they ask.
What does each connector read or write?
Different connectors carry different access profiles. Some are read-only; others support governed writes. The access profile is documented in the Security section of each connector’s reference page.
As a rule:
- ERP connectors (Business Central, Finance & Operations) support reads and governed writes - writes occur only through workflows with approval gates
- Field systems (Hilti OnTrack, Trimble) are read-only - Demiton retrieves operational data but does not write back
- Assignar supports governed writes for workforce lifecycle workflows (worker mirroring, allocation management) - all writes require explicit approval and occur through the Workflow Runtime
- Payroll connectors (KeyPay) are read-only - Demiton never modifies payroll records
- Communications connectors (Teams, SendGrid, SMTP, Discord) are write-only - Demiton sends outbound messages but reads nothing
- Document stores (SharePoint, Dropbox) support reads and, for SharePoint, site provisioning writes
- Public data sources (AusTender, ABR, BOM, CKAN) are read-only - no credentials required or stored
- Identity (Entra ID) - Demiton reads identity attributes and writes only HR-owned fields (name, role, location, employment type) as part of workforce lifecycle workflows
How are credentials stored and protected?
Credentials you provide when connecting a system are:
- Encrypted at rest using AES-256
- Never logged in plaintext
- Processed in memory only during connection setup and test - never written to disk as plaintext
- Rotatable at any time from the Systems page without re-entering other configuration
For API keys and client secrets specifically: if you suspect a credential has been compromised, rotate it in the source system and update the connector. Demiton immediately begins using the new credential.
Simulation mode
Every write-capable connector supports a simulation (dry-run) mode. When a workflow runs in simulation mode, every intended write is evaluated and logged - but nothing is committed to the connected system. The log shows exactly what would have been written, to what resource, and under what identity.
Simulation mode is active by default for new workflows. Production execution requires an explicit confirmation step.
Audit trail
Every access decision and every operation in Demiton is logged:
- What was accessed or written
- Who requested it (user identity, including Entra OID)
- When it happened
- Why access was granted or denied (the reasoning trail, not just the decision)
- What the outcome was
Audit records are retained for seven years by default, aligned with Australian financial record-keeping requirements and the seven-year retention cycle used by Tier-1 head contractors for substantiation against subcontract and head-contract claims. Logs are append-only and cannot be modified by platform users.
The dimension audit log is accessible from the Audit → Dimensions page (/audit/dimensions).
Connector security reference
Each connector’s documentation includes a Security section covering the specific permissions Demiton requests, what it reads, and what (if anything) it writes. See the Connectors section for per-system detail.