1300 71 61 41AI Security & Governance Overview
How Neighbourhood governs AI: the models we use and where they run, how we contract with AI providers, the controls and monitoring we apply, and how we respond to incidents. A companion to our Information Security Policy.
Document classification: Public (procurement-shareable) Owner / approver: Trav White, Director Version: 1.0 Effective date: 8 June 2026 Next review: 8 June 2027 (annual, or sooner on material change) Companion to: Neighbourhood Information Security Policy v1.0 (the “ISP”). The ISP is the authority; this document expands the AI-specific clauses for security and procurement reviewers. Status of claims: Controls described as current are in force today. Items marked “Planned” are roadmap commitments with target dates, not present-state claims. We do not claim controls or certifications we do not hold.
Purpose
This overview answers the AI-specific questions a security or IT team typically raises when assessing Neighbourhood as a supplier: how we govern AI, which models we use and where they run, how we contract with AI providers, the controls and monitoring we apply, how we respond to incidents, and what we are and are not certified against.
It is written to be read alongside the ISP. Where a control already lives in the ISP, we cite the section rather than restate it.
1. AI governance and framework
Neighbourhood uses AI heavily and in production. Our governance of it rests on four written commitments, all enforced today:
A named, risk-tiered action policy for all autonomous AI. Every autonomous agent acting on Neighbourhood’s behalf operates under a published Green / Amber / Red policy (ISP §6.3). Low-risk actions run autonomously and are logged. Risky, irreversible, or production-shaped actions either notify a human first (Amber) or stop and wait for explicit human approval (Red). A senior team member reviews the Red queue before anything in it proceeds.
AI is bound by the same information security policy as our people. The ISP explicitly binds “all autonomous AI agents operating on Neighbourhood’s behalf” (ISP §1). AI is not a carve-out from our security posture; it is inside it.
Least privilege applies to AI as it does to staff. Agents and AI-enabled tools receive credentials scoped to the minimum required for the task, granted per engagement and revoked at engagement end (ISP §5). An AI system cannot reach data its task does not require.
Director accountability. The Director (Trav White) is the accountable owner of the AI action policy and reviews the Red queue (ISP §3).
Governance documents of record:
- This AI Security & Governance Overview
- Neighbourhood Information Security Policy (§6 covers AI use)
- Per-project AI specifications, where a client engagement builds an AI feature (these document the data scope, guardrails, and evaluation approach for that specific build)
2. AI security and data flow
What data reaches an AI model, and what does not.
Neighbourhood’s first principle is that client data stays in the client’s own systems. We access client platforms (HubSpot, Salesforce, Google Workspace, Xero) as authorised users under least privilege, and we do not copy client data into Neighbourhood-owned infrastructure unless an engagement explicitly requires it (ISP §2, §4).
When AI is used, data flows are as follows:
| Flow | What moves | Where it goes | Controls |
|---|---|---|---|
| Delivery and internal work (code, research, drafting, analysis, meeting notes — most client work) | NBH operational content, and client data where a task requires it | Claude Team plan (Anthropic); Google Gemini (internal only); Fathom (transcription) | Commercial subscription terms: no training on inputs; least privilege; encrypted, MDM-managed Brisbane devices (ISP §6.1, §7) |
| Embedded client-tool AI features | Only the data that tool’s function requires | Anthropic API, via a per-tenant scoped key | One tenant’s data is never visible to another tenant; no client data trains any model (ISP §6.2) |
| Client platform data | Stays in the client’s platform | Not sent to any AI model unless the engagement explicitly requires it and the client has authorised it | Least privilege; access revoked at engagement end (ISP §4, §5) |
Transport and storage. All AI provider calls are over TLS. Where Neighbourhood hosts data for a client tool, it is encrypted at rest, tenant-isolated, and Australia-resident on DigitalOcean’s Sydney region (ISP §8, §10). The AI inference itself is performed by the provider (see Section 3 for region detail).
3. AI models, versions, locations, and processing regions
This is the detail the public Trust Centre summarises but does not enumerate. Full specifics:
| Provider | Use | Model family | Processing location | Data residency / retention |
|---|---|---|---|---|
| Anthropic — Claude Team plan | Primary day-to-day delivery and internal work (most client work) | Claude (Opus / Sonnet / Haiku, 4-series) via the Claude Team plan | United States (Anthropic-operated cloud) | Commercial subscription terms: no training on Neighbourhood or client inputs |
| Anthropic — API | AI features embedded inside client tools we build | Claude (4-series) via the Anthropic API, per-tenant scoped key | United States (Anthropic-operated cloud) | Commercial API terms: no training on inputs; inputs retained up to 30 days for trust and safety, then deleted |
| Fathom | Meeting transcription only | Fathom’s transcription/summarisation models | United States | Zero retention; no training on inputs; SOC 2 Type II and HIPAA |
| Google (Gemini) | Internal NBH work only (research, drafting, testing) | Gemini via the Google AI API | United States | Not used on client engagement data; internal use only |
Honest notes for reviewers:
- Processing region for generative AI is the United States. Most work runs on the Claude Team plan; embedded client-tool features use the Anthropic API. Both are Anthropic commercial products processed in US-based infrastructure. We do not currently route Claude through a region-pinned deployment (for example, AWS Bedrock in Sydney). If a specific engagement requires AI inference to be performed in an Australian region, that is a scoping conversation we can have per project, not a present-state claim.
- Neighbourhood-hosted data is Australia-resident (DigitalOcean Sydney). The US processing applies to the AI inference call, not to where we store data.
- We do not use OpenAI at all, and we do not use Google generative AI for client engagement data. Google Gemini is used internally only (research, drafting, testing) and never on client data. See Section 4.
- Model versions move as providers release updates. We track the model family and provider rather than pinning a frozen version, because newer models within a family are generally safer and more capable. Where an engagement requires a pinned version, we pin it and record it in that project’s AI specification.
4. Data Processing Agreements with AI providers
| Provider | Used for client data? | Contractual basis |
|---|---|---|
| Anthropic | Yes | Operated under Anthropic’s commercial terms (Claude Team plan for delivery work; Anthropic API for embedded client-tool features), which include a Data Processing Addendum. No training on inputs. Neighbourhood holds commercial (not consumer) terms. |
| Fathom | Yes (meeting transcription) | Operated under Fathom’s terms and DPA, with zero retention and SOC 2 Type II / HIPAA posture. |
| OpenAI | No | Neighbourhood does not use OpenAI at all. |
| Google (Gemini / generative AI) | No (internal use only) | Neighbourhood uses Google Gemini for internal work only (research, drafting, testing) and does not send client engagement data to it. Google Workspace is used for internal productivity under its standard DPA, separate from this generative-AI use. |
The honest position: the only third-party AI providers that touch client engagement data are Anthropic (commercial Claude Team plan and API, no training on inputs) and Fathom (zero retention). Google Gemini is used internally only and never on client data; OpenAI is not used at all. We therefore do not send client engagement data to OpenAI or Google generative AI.
Neighbourhood’s own client-facing Data Processing Agreement (under the Privacy Act 1988) is part of our standard procurement packet and available on request (ISP §14).
5. AI-specific security controls
Reviewers asked specifically about prompt injection, data-leakage prevention, model abuse, and output filtering. Here is what is in force today, and where we are honest about limits.
Prompt injection. Our primary defence is architectural, not a content filter: an autonomous AI agent cannot perform a risky or irreversible action on its own, regardless of what instruction reaches it. The Green / Amber / Red policy (ISP §6.3) means an injected or malicious instruction still cannot, for example, delete data, change production configuration, or alter access, because those are Red actions that stop and wait for explicit human approval. Combined with least-privilege scoped credentials, a compromised prompt cannot reach data or systems outside the task’s scope.
Data-leakage prevention. - Zero-retention provider terms: inputs are not retained by providers for training (ISP §6.1). - Per-tenant key isolation: one client’s data is never visible to another client’s instance (ISP §6.2). - Client data is not copied into Neighbourhood infrastructure unless explicitly required (ISP §4). - Secrets are never sent to a model: they live in Dashlane or platform secret stores, are scanned for at every code push, and are blocked from entering code (ISP §8, §9). - No client data enters development environments or repositories (ISP §5, §9).
Model abuse. Client-tool AI features run on dedicated, per-tenant API keys, which bounds usage to that tenant and lets us detect and cut off anomalous consumption. Anthropic and Fathom also operate their own platform-level safety and abuse controls.
Output filtering. For production-shaped actions, the control is human-in-the-loop: Amber and Red actions surface to a person before they take effect (ISP §6.3). Where a client engagement builds an AI feature, output guardrails and evaluation suites are documented in that project’s AI specification (ISP §6.2). We do not currently run a standalone, organisation-wide automated output-filtering layer across all AI use; building one is on our roadmap (Section 7 / ISP §14). We would rather state that plainly than imply a control we do not operate.
6. AI monitoring and logging
In force today:
- Every autonomous agent action is logged under the Green / Amber / Red policy, and the Red queue is reviewed by a senior team member before actions proceed (ISP §6.3).
- Repository and code activity is logged and retained
across the
nbh-coGitHub organisation, with secret scanning and push protection so secrets cannot enter code (ISP §9). - Access is reviewed at every project milestone, and credentials are revoked on engagement end and on suspected compromise (ISP §5, §8).
Honest limits: Our monitoring today is action-level and access-level. We do not currently operate a dedicated data-loss-prevention (DLP) layer that inspects every AI input and output for sensitive-data exposure in real time. Enhanced AI input/output monitoring is a roadmap item alongside the broader observability work in ISP §14. Where an engagement requires tighter per-tool monitoring, we scope and document it in that project’s AI specification.
7. Incident response and breach management
Neighbourhood maintains a documented incident response plan aligned with the Australian Notifiable Data Breaches (NDB) scheme under the Privacy Act 1988. It is rehearsed, not published once (ISP §2.5, §12). The plan:
- Identify and contain — isolate affected systems, revoke compromised credentials, stop further exposure.
- Notify — affected clients informed within 24 hours of a confirmed incident.
- Investigate — root cause analysis, scope of exposure, forensic timeline.
- Remediate — patch the root cause, rotate all potentially affected credentials, post-mortem.
- Report — notify the Office of the Australian Information Commissioner (OAIC) where required under the NDB scheme.
This plan applies to AI-related incidents on the same terms as any other: an AI agent that breaches the tiered action policy is halted, logged, and reviewed by the Director (ISP §6, §15). Vulnerability reports are acknowledged within one business day, and we operate a good-faith safe-harbour for security researchers (ISP §12).
8. Certifications
We state this plainly, consistent with our published policy of not claiming certifications we do not hold (ISP §2.3).
Neighbourhood is not currently SOC 2 or ISO 27001 certified. Our roadmap (ISP §14):
| Item | Status |
|---|---|
| Australian Privacy Act 1988 and APPs | Aligned, current |
| Notifiable Data Breaches scheme | Aligned, current |
| OWASP Top 10 secure development | Aligned, current |
| ACSC Essential Eight | Self-assessed (ISP Appendix A) |
| Annual external penetration test (NBH-hosted services) | Planned, Q4 2026 |
| SOC 2 Type I readiness (NBHOS and client tools) | Planned, 2027 |
| ISO 27001 gap assessment | Planned, 2027 |
Our AI subprocessors are independently certified, which is the certification most relevant to AI risk:
| Provider | Certifications |
|---|---|
| Anthropic | SOC 2 Type II; no training on inputs |
| Fathom | SOC 2 Type II, HIPAA, zero retention |
| DigitalOcean (hosting, Sydney) | SOC 2 Type II, SOC 3 |
| Cloudflare (edge, WAF, TLS) | SOC 2 Type II, ISO 27001, ISO 27018 |
Neighbourhood also holds Professional Indemnity, IT Liability, and Public Liability insurance to $5m (Berkley Insurance Australia, renewed February 2026). A Certificate of Currency is available on request (ISP §14).
Procurement packet
The following are kept current and provided to client security and procurement teams on request:
- This AI Security & Governance Overview
- Neighbourhood Information Security Policy (full)
- Mutual NDA
- Data Processing Agreement (under the Privacy Act 1988)
- Insurance Certificate of Currency
- Trust Centre: nbh.co/trust-centre (public summary and current subprocessor list)
This document is maintained in the Neighbourhood knowledge base alongside the Information Security Policy, and summarised publicly at nbh.co/trust-centre.
.svg){kind=logo}
