Security by ownership.Your repo. Your cloud. Your perimeter.
Most AI vendors ask you to trust their infrastructure with your data. We build inside yours. The code ships to your GitHub, the agents run in your cloud account, and nothing leaves a perimeter you already control. 187N is committed to the confidentiality, integrity, and availability of what we deliver — and to aligning every build with the compliance standards your business already operates under.
Request security documentsEnterprise-level security.Without handing anyone your data.
Isolation by design.
Every agent runs sandboxed, with scoped permissions per integration. The Resolution Agent can process a refund; it cannot touch your ad account. Blast radius is defined before deploy, not discovered after.
Full transparency.
No black box. The code is in your repo, readable by your team, auditable line by line. Every agent action writes to an immutable log — who, what, when, why.
Data sovereignty.
Your data never moves into 187N infrastructure, because 187N infrastructure doesn't exist in your build. Orders, tickets, and customer records stay in your cloud, your region, your jurisdiction.
Operator-defined rails.
You set the thresholds: which actions run autonomous, which need a human signature, which are off-limits entirely. Approvals route to Slack or Telegram. Rails are config, not promises.
Provable by architecture.Not by promise.
We build systems that act on your customers and your money. That's powerful to deploy and dangerous to deploy wrong — so every build ships with sandboxing, rails, and logs as defaults, not add-ons. Security isn't a tier. It's the floor.
Overview
A 187N build is custom infrastructure, so its security posture is documented per build, not per platform. Every engagement ships with an architecture document, a permissions map per agent, a data-flow diagram showing exactly what touches what, and runbooks for incident handling.
The documents below describe the standards every build starts from. Your build's specifics live in your handoff pack.
Compliance
Request access to documents187N operates from the Netherlands under GDPR. Builds for EU brands keep customer data in EU regions of your cloud account. Data processing agreements are signed per engagement.
Your build runs on AWS or GCP infrastructure that holds ISO 27001 and SOC 2 Type II. Because the system lives in your account, those certifications cover your deployment directly — no vendor in between to audit.
All inference runs through the Anthropic API under commercial terms: inputs and outputs are not used for model training. Model and data-handling documentation available on request.
Every build is delivered against a written security spec: agent permissions, approval thresholds, data flows, and incident procedures — signed by both parties before deploy.
Monitoring
Request access to documentsControls. Continuously, per build.
- Every change ships as a reviewed pull request in your repo
- Staged deploys: dev → staging → production
- Rollback procedures documented in runbooks
- Runs on your cloud's availability zones and SLAs
- Health checks and dead-letter queues per agent
- Failure alerts route to your Slack within minutes
- Least-privilege credentials per agent, per integration
- No standing 187N access after handoff — access granted and revocable by you
- Key rotation procedures in the handoff pack
- Customer data never leaves your cloud account
- Secrets managed in your cloud's secret manager, never in code
- No training on your data at any layer
- Dependency scanning in the repo's CI pipeline
- Patch procedures documented for your team or covered under maintenance
- Per-build incident runbook: detect, contain, roll back, report
- Kill switch per agent in Mission Control — one command, agent paused
- Post-incident log review with full audit trail
- Pre-deploy audit maps data flows and failure modes before any code runs
- Approval thresholds set per action class during the build spec
- Agents communicate over your cloud's private networking where available
- All external calls over TLS; API keys scoped and rotated
- Two named partners accountable per build — no anonymous offshore handoff
- Build-spec signed by both parties before development starts
- Inherited from your cloud provider's data centers (ISO 27001 / SOC 2 scope)
Resources
Request access to documentsSubprocessors
Most vendors need a long subprocessor table. Ours is short, because the architecture is the privacy policy.
| Party | Role | Your data exposure |
|---|---|---|
| Your cloud account (AWS / GCP) | Hosting, storage, networking | Everything — under your contract, your keys, your region |
| Anthropic API | Model inference | Prompt context per request. Not used for training. Enterprise terms. |
| GitHub (your org) | Code repository | Code only. No customer data. Repo owned by you. |
| Your existing stack | Source systems (Shopify, Klaviyo, Gorgias…) | Already yours — agents connect with scoped credentials you issue |
Agreements
FAQ
Below are frequently asked questions about the handling of data and information security measures in 187N builds.
