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.
Evaluating Demiton for a security review? Request the Security Whitepaper.
How does Demiton enforce identity-bound execution?
Section titled “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?
Section titled “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 (Employment Hero Payroll) |
| 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
Section titled “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?
Section titled “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?
Section titled “What does each connector read or write?”Different connectors carry different access profiles. Some are read-only; others support approved 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 approved 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 approved writes for workforce lifecycle workflows (worker mirroring, allocation management) - all writes require explicit approval and occur through the Workflow Runtime
- Payroll connectors (Employment Hero Payroll) support reads and approved writes - creating or updating employee records, timesheets, and leave requests - only through approval-gated workforce lifecycle workflows
- Communications connectors (Teams, SendGrid, SMTP, Discord) are write-only - Demiton sends outbound messages but reads nothing
- Document stores (SharePoint, Dropbox) are read-only except for SharePoint, which supports approved writes for document uploads and site and document-library provisioning
- Public data sources (AusTender, ABR, BOM, CKAN) are read-only - no credentials required or stored
- Identity (Entra ID) - Demiton reads identity attributes and group memberships, and supports approved writes for group membership (adding and removing members, creating security groups) and HR-owned profile fields (department, job title, city, employment type, employee ID, manager) as part of workforce lifecycle workflows
How are credentials stored and protected?
Section titled “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
Section titled “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 not on by default - it must be enabled for each run. Production execution requires an explicit confirmation step: a proposed write to a connected system is queued for admin approval at HQ → Approvals before anything is written.
Audit trail
Section titled “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
Retention target: seven years, 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. This is a design target rather than an enforced purge: audit records are append-only and are not automatically deleted today, and no scheduled job trims the audit tables. Scheduled retention jobs do exist for other stores - for example, evaluation-harness chat rows are purged after 30 days.
The dimension audit log is accessible from the Audit → Dimensions page (/audit/dimensions).
Connector security reference
Section titled “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.
Frequently asked questions
- How does Demiton enforce identity-bound access?
- 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. API requests are authenticated via your API key, MCP tool calls are bound to the user identity that established the session, and no operation is anonymous.
- What data domains does Demiton recognise?
- Demiton recognises three data domains: Operations (site diaries, forms, allocations, schedules - broad access within your functional team), Financials (project budgets, actuals, variance, purchase orders - project-scoped), and Payroll (pay records, individual hours, cost rates - restricted to payroll administrators and self-service for own data).
- How does Demiton handle credentials for connected systems?
- Credentials are encrypted at rest using AES-256, never logged in plaintext, processed in memory only during connection setup, and rotatable at any time from the Systems page. Demiton never stores credentials as plaintext on disk.
- How long are audit records retained?
- Retention target: seven years, aligned with Australian financial record-keeping requirements. This is a design target rather than an enforced guarantee - audit tables are append-only and are not auto-deleted, but no scheduled job trims them today. Other retention that is enforced is shorter, for example evaluation chats are purged after 30 days.
Talk to the team
Tell us what you run - your ERP, field, payroll and document systems - and we will show you the registers Demiton would fill from them, on your data, in a 30-minute call.