Approval-gated by default
Every customer-facing or system-changing action requires human approve / edit / reject before it leaves the building. Autonomy is earned per workflow, not assumed.
Trust & security
Trust is the product.
Approval gates, logs, data boundaries, and onshore models — the controls that let you actually use AI in your business.
Every action logged
Every tool call, approval decision, model call, and rail trip is written to an audit log. Logs are searchable and exportable.
Read-only first
Every integration starts with the minimum scope required to read. Write access is granted per workflow when the workflow needs it, and is revocable.
Approval gates
The product, not a feature.
Approval gates are the moments where a human reviews what an agent is about to do and chooses to approve, edit, or reject it. They fire on any customer-facing message, any write to a CRM, calendar, or document store, and anything tagged as sensitive in the client policy. The approver is configurable per workflow — usually the workflow owner, an admin, or a named manager — and approvals can be routed by data classification, value threshold, or business hours. Every decision is recorded with a timestamp, the user, the original AI output, any edits made, and the rationale captured at decision time. Nothing customer-facing or system-changing leaves the building without that record.
Logs and audit trail
Every action is recorded, retained, and exportable.
We log every tool call with its parameters, every approval decision with reviewer metadata, every model call with the provider, model name, and cost, and every rail trip with the trigger that fired it. Retention defaults to twelve months and is configurable per client policy — longer where regulation requires it, shorter where the client prefers. The client owner and the platform operator can search and export the audit log at any time, in CSV or JSON, scoped to a workflow, a date range, or a single approval.
Data boundaries
Five classification levels. Every workflow is mapped to one.
Before a workflow goes live, every input and every output is mapped to a data classification level. The level determines who can approve, what can be logged in plain text, and which providers are allowed to see it. The classification is part of the client's policy document and is reviewed when the workflow changes.
| Level | Description | Handling |
|---|---|---|
| L0 | Public | Can be used in demos and low-risk workflows |
| L1 | Internal | Approved internal workflows only |
| L2 | Confidential | Approval-gated, restricted access, logged |
| L3 | Sensitive personal/commercial | Strict approval, minimisation, redaction where possible |
| L4 | Regulated/high-risk | Do not process until controls, contract, and legal review are complete |
L0 · Public
- Handling
- Can be used in demos and low-risk workflows
L1 · Internal
- Handling
- Approved internal workflows only
L2 · Confidential
- Handling
- Approval-gated, restricted access, logged
L3 · Sensitive personal/commercial
- Handling
- Strict approval, minimisation, redaction where possible
L4 · Regulated/high-risk
- Handling
- Do not process until controls, contract, and legal review are complete
Sovereign data residency
Onshore models, onshore data, documented per workflow.
Model calls run via Amazon Bedrock in the ap-southeast-2 (Sydney) region or Microsoft Azure in Australia East where the chosen model is supported. Customer data stays onshore. Each deployment includes a model-region check before go-live: if the requested model is not available in an Australian region, we either substitute a model that is, or flag the workflow as out of scope. The model and region are documented in the client's policy and reviewed monthly.
Guarded LLM
Guardrails wrap the model. They do not sit downstream.
Step 01
Input rails
Step 02
LLM call
Step 03
Output rails
Topical, dialog, policy rails — applied throughout
Guardrails wrap the LLM, not just sit downstream. Input rails validate the request before it reaches the model. Output rails check the response before any action is taken. Topical, dialog, and policy rails constrain what the model is allowed to discuss and do at every step (NVIDIA NeMo Guardrails rail types).
Risk tiers
Five tiers. Higher tier, tighter control. Tier 5 is out of scope.
Every workflow is assigned a risk tier during the audit. The tier sets the minimum control level — logging and review at the bottom, human approval in the middle, enhanced review and restricted scope at the top, and an outright "no" at the ceiling. Tier 4 and tier 5 workflows require additional sign-off from the client owner before we build them.
| Tier | Workflow type | Control level |
|---|---|---|
| T1 | Internal summaries, low-risk admin | Logging + review |
| T2 | Drafting internal/customer messages | Human approval |
| T3 | CRM/job/accounting updates | Approval or strict policy controls |
| T4 | Financial/legal/HR-sensitive workflows | Enhanced review, restricted scope |
| T5 | Regulated/high-impact decisions | Out of scope |
T1
- Workflow type
- Internal summaries, low-risk admin
- Control level
- Logging + review
T2
- Workflow type
- Drafting internal/customer messages
- Control level
- Human approval
T3
- Workflow type
- CRM/job/accounting updates
- Control level
- Approval or strict policy controls
T4
- Workflow type
- Financial/legal/HR-sensitive workflows
- Control level
- Enhanced review, restricted scope
T5
- Workflow type
- Regulated/high-impact decisions
- Control level
- Out of scope
Model and provider register
We publish what we use, per workflow.
We publish the model and provider for every workflow. The register is part of the client's policy document and reviewed monthly. Clients can restrict providers in their policy — for example, "no provider outside Australian regions" or "no provider with US-only inference." If a workflow needs a model that doesn't fit the register, we raise it before building, not after.
Incident response
A defined severity scale, a defined escalation path.
We use a four-level severity scale. S1 covers customer or data exposure. S2 covers a workflow failure where an action was sent before it was caught. S3 covers a workflow failure that was caught by an approval gate before any action left the building. S4 covers minor or cosmetic issues that don't affect operations.
Escalation runs operator → platform owner → client owner, within defined SLAs per severity. S1 incidents are notified to the client owner within 24 hours, with a full root-cause analysis delivered within 5 business days.
Contact
Security and disclosure.
ABN
51 559 921 362
Insurance
Professional indemnity and cyber liability cover (placeholder details available on request).
Security questions
Responsible disclosure
If you've found a security issue in our platform or one of our deployments, email security@aaogroup.au. We acknowledge within 2 business days.
Ready to put controls around your AI?
A 15-minute audit call. We'll walk through approval gates, data boundaries, and what onshore looks like for your workflows.