Trust and security

What your stakeholders tell us stays yours.

Agentic Discovery generates a new class of organisational data: structured process intelligence derived from stakeholder interviews. Agent One handles it with the same rigour as client personal information, on infrastructure built to satisfy procurement teams.

01Architecture principles

Five decisions the platform is built on.

Each of these is enforced by infrastructure configuration, not by a promise in application code.

Cell-based deployment

Each client gets an isolated Google Cloud project, network and database. No shared infrastructure between engagements, enforced at the infrastructure level rather than in application code.

Data stored in Australia

Every resource that holds data — database, object storage, embeddings, secrets, compute — is locked to Australian regions by an organisation policy, not by convention. Another jurisdiction is handled per engagement rather than by exception.

Read-only discovery

Agent One reads and analyses. It holds no write access to your operational systems, so discovery cannot alter the environment it is studying.

Zero-trust identity

Workload identity federation with service account impersonation. No service account keys are created or imported, and creating them is blocked by organisation policy.

Model processing under contract

Every model call runs through Google Cloud Vertex AI, never a third-party API. Where a model is not served from an Australian region, that inference is processed elsewhere in Google Cloud under Google’s data processing terms — which prohibit training on customer data.

02Infrastructure controls

What that looks like in configuration.

The detail a procurement or security review will ask for, without the meeting.

Security controls and how each is implemented.
DimensionImplementation
Storage residencyOrganisation policy locks every resource location — data, compute, secrets — to Australian regions
Model processingVertex AI only. Inference for a model not served in Australia is processed in another Google Cloud region under Google’s data processing terms; regions named on request
Network isolationPer-cell virtual network; internal-only ingress, with no public service URL as a backdoor
TLS floorTLS 1.2 minimum, enforced at organisation policy and load balancer level
IdentityWorkload identity federation plus impersonation. No service account keys.
DatabasePrivate IP only, no public endpoint. Row-level security per engagement.
Object storagePublic access prevention enforced; uniform bucket-level access
ComputeShielded VMs required, OS Login enforced, serial port disabled, no external IPs
Service account keysKey creation and upload blocked by organisation policy
Default grantsAutomatic IAM grants for default service accounts disabled
IngressApplication traffic accepted only from the internal load balancer

03Data governance

The interview data lifecycle.

Interview data is stored in the client’s isolated cell, in Australia, and stays there. It is never aggregated across clients and never reachable from another engagement. The only thing that leaves the cell is a model call to Vertex AI — one governed path out, and no third party in between.

When an engagement concludes, retention follows the policy you specify. Everything can be exported or deleted on request: transcripts, embeddings, blueprints and findings.

deployment topology · one cell per engagement

storage · australia-southeast1

Google Cloud · Sydney

all stored data

Engagement A

own project · own VPC

  • Cloud Runapp + worker
  • Cloud SQLpgvector · private IP
  • Cloud Storageartefacts

Engagement B

own project · own VPC

  • Cloud Runapp + worker
  • Cloud SQLpgvector · private IP
  • Cloud Storageartefacts

separate projects · no shared database

one path out · prompt and response only

Vertex AI · model inference

region depends on the model

Stays inside Google Cloud, under data processing terms that prohibit training on customer data. Models not served from an Australian region are processed in another Google Cloud region; no call carries data from another engagement, and no third-party AI vendor is in the path.

One cell per engagement: its own Google Cloud project, VPC and database, all of it in Australia. Because no two engagements share a database, there is no single store that a query could aggregate across clients. Model inference is the one thing that crosses the boundary, and it crosses through a single governed path.

04Compliance

Where certification stands, honestly.

Agent One’s controls are built against the SOC 2 trust criteria, and formal certification is on the roadmap. Until certification completes we publish the roadmap rather than claiming the badge — a security questionnaire that takes our word for it is not worth much to you.

  • SOC 2Controls in place; certification on the roadmap
  • ISO/IEC 27001On the roadmap
  • APRA CPS 234 alignmentFor regulated clients, on request

Documentation available on request

  • Architecture diagram
  • Data flow diagram
  • Privacy impact assessment
  • Vendor security questionnaire, pre-filled

In preparation

Privacy policy · Data processing agreement · Information security policy · Sub-processor register · Incident response and breach notification plan · Business continuity and disaster recovery plan. Ask us where any of these stands — we will tell you straight rather than send a draft.

05Security questions

Bring your hardest ones.

Can our security team review the architecture?

Yes. We will walk your team through the cell architecture, the identity model and the data flows in as much detail as you want, and provide the diagrams and a pre-filled vendor questionnaire on request.

What happens to our data at the end of an engagement?

Retention follows the policy you specify at the start. Everything is exportable, and deletion covers transcripts, embeddings, blueprints and findings — not just the visible records.

Which models see our data, and on what terms?

Every model call is made through Google Cloud Vertex AI — frontier models for analysis and synthesis, a real-time audio model for voice, and an embedding model for semantic memory. Vertex AI’s data processing terms prohibit training on customer data, and no call goes directly to a model provider’s own API from inside a client cell. We will name the specific models under NDA for a security review.

Is any of our data processed outside Australia?

Storage is not: your data is held in Australian regions, locked there by organisation policy. Model inference can be. Some of the frontier models we rely on are not served from an Australian region, so those calls are processed elsewhere in Google Cloud — inside Google’s infrastructure, under the Cloud Data Processing Addendum and the Vertex AI service terms, which prohibit training on customer data. Nothing is handed to a separate AI vendor. We will name the serving regions and provide the terms for your review, and where processing residency is a hard requirement we will work it through with your security team before the engagement starts.

Security questions? Bring your hardest.

We are happy to walk your team through the architecture in detail, at whatever depth your review needs.