Security & Privacy

Aegis Eight only reads the Microsoft 365 security and configuration information required to assess Essential Eight compliance. It cannot modify your tenant and cannot access email, files, Teams messages, or other user content. The rest of this page explains exactly how, in plain English — no marketing copy.

Last reviewed 2026-06-06. The canonical source-controlled version of this document lives in docs/security.md in the Aegis Eight repository.

1. Trust model — what consent actually grants

Microsoft Graph is Microsoft’s official API for securely accessing Microsoft 365 configuration and security settings.

Aegis Eight is a multi-tenant Microsoft Entra application with Application permissions (background, daemon-style access). When a Global Administrator grants admin consent, a service principal of Aegis Eight is provisioned inside their tenant. From that point on the worker authenticates with the OAuth2 client_credentials grant — server-to-server, no user context, no session, no impersonation.

Every permission Aegis Eight requests today is read-only, and there is no delegated-write surface anywhere in the product. Any future feature requiring write access would be introduced through a separate, explicit consent process — never bundled into the default assessment permissions.

2. Exactly what we access, and why

The authoritative list is rendered on /permissions and matches the Microsoft consent screen exactly. The pattern Aegis Eight commits to:

• Least privilege. A scope is added only when a collector that needs it ships. Scopes are never reserved “for future use”.
• Read-only. No *.Write.* or *.ReadWrite.* scope appears anywhere in the request set.
• Mapped to a control. Every scope appears next to the Essential Eight strategy it supports. Scopes that cannot be mapped to a customer-visible finding are not requested.
• Incremental on uplift. New collectors that source higher-tier evidence require their own scopes, added transparently before the consent screen changes.

3. Data handling

What we collect

The worker pulls configuration and posture data from Microsoft Graph: user MFA registration status, device compliance state, directory role assignments, Microsoft 365 Backup protection-policy summaries, and similar.

We do not collect:

• Mailbox content, OneDrive files, SharePoint documents, Teams messages, calendar entries, or any other user content.
• Authentication credentials, MFA secrets, recovery codes, or password material.
• Network telemetry, endpoint agent data, or device-side artefacts.
• Personal information beyond what is necessary to render a finding — a username on a “no MFA” line item, a device name on a “not compliant” line item.

Where it lives, and for how long

These responses contain security and configuration metadata only. Aegis Eight does not collect email content, documents, Teams messages, or other user-generated content — the “raw Graph response bodies” above are configuration and posture data such as MFA registration status, device compliance state, and role assignments.

Per-tenant overrides. Customers who need a shorter retention window can request a tenant-scoped override. The mechanism is a configuration field, not a code change. Default stays 90 days.

Deletion on request. A Global Administrator who removes Aegis Eight from their tenant can additionally request full data deletion. We honour that request within 30 days and confirm in writing. Anonymised aggregate metrics that do not contain tenant-identifiable data are exempt; everything else is purged.

What we never do with it

Hard commitments — reviewed each release and reflected in engineering practice:

• No machine-learning training. Aegis Eight does not use customer Microsoft Graph data to train any machine-learning model — ours, a vendor’s, or a third-party’s. No exceptions. This applies to embeddings, fine-tunes, retrieval indexes, and any other ML artefact. The product contains no ML model in any inference path today, and that is by design.
• No third-party data sharing. Customer Graph data is not sold, rented, or shared with brokers, advertising networks, or analytics vendors. The sub-processor list below is operational dependencies, not data partners.
• No cross-tenant correlation. Findings derived from one customer’s tenant are never combined with another customer’s data in the same query, report, or dashboard. Aggregate statistics for product roadmap are computed offline and only released anonymised, with a minimum cohort size that prevents tenant re-identification.
• No customer impersonation. All Graph access uses the application service principal. The worker has no path to act as a specific user, and no delegated tokens are persisted.

Encryption

• In transit. All Graph API traffic, all customer ↔ Aegis Eight traffic, and all internal service-to-service traffic is TLS 1.2+. HTTP listeners do not exist in production.
• At rest. The database, object storage, and the secret store are encrypted at rest with managed keys. Customer-scoped tokens — when stored — are additionally encrypted with a per-tenant data key derived from a managed root key.

Data residency

All customer data stays in Australia. Every scan snapshot, raw Graph evidence body, generated report, and database row is stored and processed in our Australian hosting region (Sydney). We do not replicate or fail over customer data to regions outside Australia.

• Storage and compute. The database, object storage, background workers, and the secret store all run in the Australian (Sydney) region.
• Email delivery. Report and alert emails — including any PDF attachment — are generated and dispatched from within the Australian region.
• Limited exceptions. A small number of operational sub-processors (see below) may process limited non-Graph metadata — such as your contact email or authentication identifiers — outside Australia to deliver their service. Customer Microsoft Graph posture data is never among it.

If your organisation has a contractual or regulatory requirement to keep data within a specific jurisdiction, this is the commitment to cite: by default, Graph-derived assessment data is held exclusively in our Australian (Sydney) region.

Need a different region or cloud? For customers with data-residency requirements outside Australia, Aegis Eight can deploy a dedicated instance in your required cloud and region (subject to availability) as part of an enterprise arrangement. Talk to us about your jurisdiction and we will confirm the target region before any data is collected.

4. Tenant isolation

Customer tenants are isolated from each other by construction:

• Per-row scoping in the database. Every row that holds customer data carries an azure_tenant_id foreign key. All read queries filter on it; there is no global query path that traverses tenants without explicit scoping.
• Per-tenant credentials. Aegis Eight authenticates to each customer’s Graph endpoint with that tenant’s azure_tenant_id baked into the OAuth flow. There is no “Aegis Eight superuser” token.
• Per-tenant evidence partitioning. The evidence store keys responses under evidence/{tenantId}/{scanId}/{responseHash}.json. Bucket-level IAM policies restrict the worker role to operate only on objects under that prefix.
• Single-tenant rendering paths. The dashboard and PDF report code paths take a tenantId parameter at the entry of every request handler. There is no shared cache, in-memory index, or join surface that mixes tenants.

This is enforceable at the database and IAM layers, not just in application code — the kind of isolation an external assessor can verify, not just take on trust.

5. Evidence chain — provenance, not just findings

The reason this section exists is the January 2026 IRAP Quality Assurance Framework and the parallel insurer expectation of enforcement evidence. A report that says “MFA registration is at 98%” without showing the underlying Graph response, the timestamp, and a hash of the bytes is increasingly hard to defend.

• Every finding is bound to a Graph response. Each finding carries an evidenceSource with queriedAt (UTC), endpoint (the exact Graph URL), responseHash (SHA-256 of the response body), and snapshotRef (the row id of the persisted scan).
• responseHash is the integrity claim. Even if the storage layer is re-keyed, migrated, or compromised, responseHash lets the customer confirm whether a stored body matches what Aegis Eight scored.
• Tier discipline is structural. ASD’s evidence tiers (Excellent / Good / Fair / Poor) are derived from a meaning-shaped evidenceType discriminator and enforced in code, not picked per-finding by a human. This prevents tier inflation by construction.
• The roadmap is honest about today’s tier. Aegis Eight’s current Graph-snapshot collectors land at the Fair tier — the conservative interpretation of ASD’s definition. Path 2 collectors (sign-in logs, device-config-state RSoP, Conditional Access what-if) lift specific findings to Good by sourcing applied state and enforcement evidence rather than declared configuration. The synthetic-test (Excellent) tier is reserved up front but sequenced post-MVP. Each upgrade ships with an upgradePath annotation surfaced in the report.

The customer-visible artefact: every per-finding evidence cell in the PDF report cites the live Graph endpoint queried, the UTC timestamp, the responseHash prefix, and a snapshot reference. An assessor reviewing the report can trace any finding back to its original bytes without taking Aegis Eight’s word for it.

6. Sub-processors

The vendors that may see customer data in the course of delivering Aegis Eight:

The specific hosting and email providers are selected per deployment to meet each customer’s residency and contractual requirements, and are confirmed in writing before any data is collected. We will give 30 days’ notice via the customer dashboard and email before adding a new sub-processor that has access to scan data.

7. Customer control

A Global Administrator can fully sever the relationship at any time:

Revocation takes effect immediately at the Microsoft side; the next scan attempt will fail with an authorisation error and the dashboard will surface a “we lost access” state.

• Scheduled scans stop within one cycle of failure detection.
• Change alerts and report emails stop.
• On request, scan data, evidence-store responses, and report PDFs are purged from object storage and the database within 30 days.

Customer data is never retained beyond the documented retention window for marketing, benchmarking, or analytics purposes after revocation.

8. Compliance posture

Aegis Eight is designed against the principles of SOC 2 Type II, ISO/IEC 27001, and IRAP — least privilege, evidence trails, encryption-at-rest defaults, sub-processor disclosure, change-management discipline. Aegis Eight does not currently hold any of those certifications. The product is at MVP scale; certification is appropriate for a later stage of the business and we will not claim it before it is true.

• The product is built so that adopting one of those frameworks later is a process and audit cost, not a re-architecture cost.
• For customers who need certified vendors today, Aegis Eight is honest that it is not the right fit yet. We will sign appropriate non-certified contractual commitments (DPAs, security schedules, MNDAs) in lieu of certification.
• For customers building toward an IRAP submission, Aegis Eight’s reports are designed to support that submission — the evidence chain is built for IRAP-QAF — but the assessment itself is the customer’s, not Aegis Eight’s. We are not an IRAP-assessed system and do not represent ourselves as one.

Indicative roadmap

These targets are indicative and depend on business stage; we will update this page as plans firm up, and will not claim any milestone before it is achieved.

For a security questionnaire, draft DPA, or detailed control-mapping, contact [email protected].

9. Frequently asked questions

10. Vulnerability reporting

Security researchers, customers, and the public are encouraged to report suspected vulnerabilities or data-handling issues to [email protected].

We acknowledge reports within two business days, prioritise within five, and disclose fixed issues to affected customers if customer data was demonstrably at risk. Production secrets, customer Graph tokens, and database credentials are out-of-scope for any test that would require active exploitation against a production tenant.

11. Document history

This document is versioned with the source repository. Material changes are noted in the commit history of docs/security.md.

Questions? [email protected] · View the permissions list