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.
Trust and security
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
Each of these is enforced by infrastructure configuration, not by a promise in application code.
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.
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.
Agent One reads and analyses. It holds no write access to your operational systems, so discovery cannot alter the environment it is studying.
Workload identity federation with service account impersonation. No service account keys are created or imported, and creating them is blocked by organisation policy.
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
The detail a procurement or security review will ask for, without the meeting.
| Dimension | Implementation |
|---|---|
| Storage residency | Organisation policy locks every resource location — data, compute, secrets — to Australian regions |
| Model processing | Vertex 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 isolation | Per-cell virtual network; internal-only ingress, with no public service URL as a backdoor |
| TLS floor | TLS 1.2 minimum, enforced at organisation policy and load balancer level |
| Identity | Workload identity federation plus impersonation. No service account keys. |
| Database | Private IP only, no public endpoint. Row-level security per engagement. |
| Object storage | Public access prevention enforced; uniform bucket-level access |
| Compute | Shielded VMs required, OS Login enforced, serial port disabled, no external IPs |
| Service account keys | Key creation and upload blocked by organisation policy |
| Default grants | Automatic IAM grants for default service accounts disabled |
| Ingress | Application traffic accepted only from the internal load balancer |
03Data governance
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
Engagement B
own project · own VPC
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.
04Compliance
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.
Documentation available on request
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
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.
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.
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.
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.
We are happy to walk your team through the architecture in detail, at whatever depth your review needs.