We cannot see your data.
Tether's architecture is designed around a single constraint: the vendor must not be a liability. The control plane lives in your tenant, the proxy installs no MITM root certificate, and every policy decision is cryptographically signed for offline verification.
Security controls must be verifiable.
Default Deny on Failure
If the endpoint agent cannot verify the cryptographic signature of the active policy, it blocks traffic. If a synchronous approval request times out, it blocks traffic. A security tool that fails open is a liability.
Cryptographic Policy Verification
Policies are signed at the control plane using an Ed25519 key pair owned by your tenant. The endpoint agent verifies the signature before applying the rules. Downgrade attacks and forged policies are mathematically impossible.
Zero Vendor Data Access
The control plane is deployed in your AWS or GCP environment. Data evaluation happens locally on the endpoint. Event telemetry streams directly to your SIEM. We have no access to your prompts, your policies, or your audit trail.
No TLS Interception
We do not require installing a MITM root certificate on developer machines. The proxy binds to the local loopback and evaluates the prompt before it enters the TLS tunnel. Personal and non-AI corporate traffic remains untouched and unreadable by Tether.
We do not break TLS.
The Connect proxy operates exclusively on the loopback interface. It routes encrypted tunnels straight through. It evaluates the request body only when developer AI tools are explicitly configured to route HTTP traffic through the local proxy.
We refuse to install a MITM root certificate. Tools that require a custom CA to inspect AI traffic introduce severe risk because they can intercept all TLS traffic on the machine, including personal banking.
Tether provides visibility and enforcement without introducing a new vector for systemic interception.
You can verify this claim immediately. Deploy Tether, open the operating system's trust store, and confirm there is no Tether certificate installed. The exact host-classification path is documented in the technical brief →
Who can block what,
when, and how to tell.
Here's the whole model: Tier 0 always blocks. Tier 1 is yours to configure — you opt into synchronous blocking at deploy time, and when it's on it fails closed on a timeout. Tier 2 records but never blocks.
The full breakdown lives in the technical brief · judge authority → — what each tier can block, when, and how every decision is labelled so you never mistake an advisory signal for a guarantee, with the code citations behind each line.
X-Tether-Policy-Version
on every response.
Signing proves which policy bundle Overwatch published. Per-request attestation goes one step further — it proves which bundle decided this exact request.
The proxy sets X-Tether-Policy-Version: <version> on every blocked 403 and every forwarded response. Every AI_PROXY_REQUEST event sent to Overwatch carries policyVersion. Every judge review carries it too.
Your auditor takes the event ID and makes one call. GET /api/v1/attestation/<eventId> returns a single artifact: the decision, the signed policy bundle that made it, and your tenant's Ed25519 public key.
A standalone verifier — tools/verify-attestation.js, with zero dependencies — re-checks that artifact offline: the signature, the link between the decision and its policy version, and the exact controls in force. The signed bundle also pins the judge model, so the check covers which model decided. Your auditor confirms a single decision offline, with math.
That chain — from the policy version on a request, to the signed bundle, to an offline signature check, to the controls in force — is what makes a decision reproducible. See the technical brief →
The evidence stands on its own. Your auditor pulls the signed bundle for the version that decided a request and verifies the signature offline — a standard cryptographic check they run with their own tools. If it verifies, the controls in that bundle are provably the ones in force when the decision was made.
Nothing to re-run. Nothing to take on faith. The exact response shape and the verification command are in the technical brief →
Two limits to know. In-memory events don't survive an Overwatch restart unless your SIEM adapter forwards them. The durable audit trail on disk is policy-audit.jsonl, which covers policy-publish actions — per-request event durability depends on SIEM forwarding. And tamper-evident, append-only (WORM) retention of every version bundle is a known gap for deployments that need full forensic retention.
GET /api/v1/attestation/<eventId> # returns: decision + signed policy bundle + tenant Ed25519 public key ./tools/verify-attestation.js attestation.json # re-verifies offline, zero dependencies
Your cloud account.
Your secrets. Your buckets.
Overwatch runs in your own cloud account. One Cloud Run service on GCP, or one ECS service on AWS, per tenant. Each tenant gets its own GCS bucket or EFS file system for state, and its own Secret Manager for tokens and the policy signing key.
No traffic passes through a Tether-owned server. Your custom domain terminates on your own Cloud Run instance. If you're in the EU or under regional rules, your data stays in your eu-west-1 or europe-west1 region simply because that's where you deployed it.
One thing to decide. If you point the judge at a cloud vendor like OpenAI, prompt previews go to that vendor. That's your call — Tether also supports a fully on-prem judge, a local model that keeps everything inside your environment.
You can run the whole thing air-gapped. The proxy, the judge, the control plane, and the syslog path each work with no internet dependency. The deploy detail is in the technical brief →
What Tether covers.
And what it does not.
Tether is built for one job: the risks that show up when a developer sends data to an AI tool. Here's what that covers, and where it stops.
A developer pastes proprietary code, a credential, or personal data into an AI prompt or chat. The Tier 0 floor and the synchronous judge catch known patterns, and fail closed on a timeout when you set them to.
A developer installs an extension or CLI that calls an AI API outside the approved toolchain. The proxy reads the destination host on the CONNECT tunnel, so you can block unapproved vendors.
A developer tries to change, downgrade, or replay an old policy. Signature verification plus a monotonic version number stops both tampering and replay.
You can't show an auditor that your technical controls actually worked. The append-only policy audit and per-request attestation give you evidence they can check.
Tether covers the developer's machine, not everything. It doesn't watch server-side AI traffic from your pipelines. It doesn't cover browser-only AI tools — that's your CASB's job today. And it won't stop an agent built to bypass the proxy, or a determined insider with full control of the machine; it raises the cost there, but it isn't a wall. The full out-of-scope list, row by row, is in the technical brief →
Coordinated disclosure policy.
If you find a vulnerability in Tether, we want to fix it quickly and credit you publicly. This policy describes scope, process, response timeline, and how to reach us privately.
Scope
In scope: code on master in arich2day/project-tether — Connect proxy (warden/cmd/proxy/), workspace daemon (warden/cmd/workspace/), Overwatch API (overwatch/api/), Overwatch console (overwatch/web/), VS Code extension (vscode-extension/), and the deploy Terraform (deploy/).
Out of scope: third-party dependencies (report upstream), Tether's marketing sites, social-engineering vectors, denial-of-service against a customer-deployed tenant (test against a tenant you own).
Process
Email a clear write-up, reproducer, and your preferred credit. We acknowledge within 48 hours, triage within 5 business days, and target a fix in 30 days for high-severity issues. We will coordinate disclosure timing with you.
Response time targets
Critical (RCE, signing-key compromise, auth bypass): 24-48h acknowledge · 7d fix target.
High (privilege escalation, policy verification bypass): 48h acknowledge · 30d fix target.
Medium / Low: 5 business days acknowledge · best-effort fix.
For reports requiring transport encryption, request our key by email before sending details.
Good-faith research under this policy is not subject to legal action by Tether. Do not access customer data, do not exfiltrate, do not disrupt service.
We maintain a public Hall of Thanks. You decide whether you want to be listed.
What we produce.
Not what we sign for you.
Tether isn't SOC 2 certified as a SaaS — because we don't host your data. What we give you instead is evidence that maps to your own SOC 2 CC6, CC7, and CC8 controls, verifiable without trusting us.
CC6 logical access (SCIM via Jackson + role-from-groups + audit). CC7 system monitoring (SIEM fan-out + posture heartbeats). CC8 change management (Ed25519-signed bundles + append-only audit + per-request attestation).
Your auditor can re-verify any single decision offline — the decision, the signed bundle, and the public key all arrive in one artifact. That kind of per-request provenance, which doesn't rest on trusting the vendor, is exactly what federal-grade diligence looks for. We claim no FedRAMP status or authorization. We produce the evidence that kind of diligence asks for.
Documented technical controls over AI data handling, an audit trail of AI-usage decisions, risk-based evaluation, and policy versioning. Map it to your AI-governance program — we won't pretend to interpret the EU AI Act for you.
Bring your threat model.
We will walk it through ours.
A 30-minute review with your CISO, your AppSec lead, or your compliance team. We come with the code citations; you bring the questions.