Controls

Stop the bleeding. Prove the fix.

You define the boundaries for AI data egress. Tether enforces them deterministically at the endpoint and generates cryptographically signed proof for every decision.

Built for compliance.

A security control is only as good as the evidence it provides. We built Tether for the auditor.

01 · VISIBILITY

Full payload and attribution

Capture the prompt, the response, the exact identity of the sender, the specific developer tool used, and the host machine—all pushed to your SIEM.

02 · ENFORCEMENT

Deterministic rule execution

We do not rely on probabilistic models to block traffic. Enforcement is based on strict, deterministic regex and YARA signatures that you define.

03 · EVIDENCE

Offline verifiable proof

Every decision is cryptographically signed using an Ed25519 key, tied to the exact policy version in force. Hand the bundle to an auditor to verify offline.

Mechanisms, not promises.

The concrete features that deliver control. For implementation details, refer to the technical brief.

No surveillance backlash

Govern the AI channel without a root certificate on a single laptop.

Why it matters
Developer-aware orgs push back hard on corporate root certificates — the same cert that decrypts a Cursor call decrypts a developer's banking session. Tether governs the egress channel without that cert, so you get the control and skip the fight — unlike CASB/DLP stacks that demand a CA install.
What it does
The proxy runs locally and never decrypts TLS-tunneled content. It classifies the destination and reads the prompt only on the AI routes you've approved. One limit: a tool that refuses to route through the proxy isn't governed — we'll tell you which.

A floor you can name and rely on

The patterns you define are blocked deterministically — no model, no opinion.

Why it matters
For known credential formats and the internal customer-ID patterns you author in week one, you get a guarantee, not a probability — no model in the path, no network call. It's the layer a SOC 2 CC8 auditor can attest against, because the decision is deterministic and reproducible.
What it does
Matching content is blocked at the source; nothing leaves. The base floor is immutable; you add your own patterns through signed policy, and a false-positive fix reaches the fleet in about ten seconds.

Policy that reaches everyone, fast

Author once; the whole fleet enforces it in about ten seconds, tamper-proof.

Why it matters
Most policy-distribution takes minutes to hours; a ten-second bound matters during an incident. Each policy is cryptographically signed and can't be downgraded or replayed, so you get change-management evidence that maps cleanly to SOC 2 CC8 — your auditor decides what they accept.
What it does
The control plane signs each published policy; every machine verifies before applying and acknowledges with hostname and version, so you see real fleet-adoption state. A failed verification is discarded — the machine keeps the last good policy or blocks egress.

A judge you supply — and pay nothing for

Weigh ambiguous content with your own model. On-prem capable.

Why it matters
The judge is customer-supplied: model spend goes to your own vendor, not a Tether markup, which keeps per-seat economics honest. On-prem and air-gapped teams run a local model and never leave their boundary. And it fails closed — a network adversary can't defeat a block by stalling the judge.
What it does
For content the floor can't name, the proxy can consult a model you provide — local or your own cloud vendor — to weigh risk, with sampling you tune so cost stays predictable. Genuinely novel or oversized requests are always escalated.

Which decisions block, and which just advise

You always know whether a decision was a hard block or an advisory note.

Why it matters
"The judge said allowed" and "the request was allowed" are different statements, and a control that blurs them isn't one you can stand behind to an auditor. Tether labels which is true for every decision, so a hard block is a guarantee and an advisory note is exactly that.
What it does
Enforcement runs in three tiers: a floor that always blocks, an opt-in synchronous check that blocks and fails closed, and an advisory pass that records but cannot change the request it observed. The exact authority of each is in the technical brief →

Lands in the SIEM you already run

Splunk, Microsoft Sentinel, or syslog — your platform team writes no code.

Why it matters
The AI-egress channel finally shows up where your security team already looks. A platform engineer who knows Splunk or Sentinel wires it up in an afternoon, no custom development. Event volume is light relative to a typical SIEM ingest budget — ask and we'll give you a sizing range for your seat count and tool mix.
What it does
Every event fans out in parallel to the SIEM adapters you register, with built-in retry. Signed outbound webhooks ride the same path — filtered so each receiver sees only what it cares about.

Operator seats from your own directory

SSO and SCIM via your IdP — no separate user list to manage.

Why it matters
Nobody manages users in yet another console. Seats provision from your IdP, role follows group membership, and a deprovision in Okta or Entra cuts access automatically — every change audited, mapping to CC6 logical-access controls your auditor already understands.
What it does
SAML and OIDC sign-in plus directory sync run through a managed identity layer. Group names map to admin, operator, or viewer roles; every provision, update, and deprovision lands in the audit trail.

Device posture your IdP can read

Conditional access sees Tether's signal in a format it already understands.

Why it matters
Your conditional-access policy reads Tether posture without a custom converter. A machine that's fallen out of compliance — proxy off, agent stale — drops out of the device-trust set automatically. Your Okta and Entra teams already know the shapes.
What it does
Posture exports in Tether-native, Okta Device Trust, Microsoft Graph managedDevice, and CSV formats, with filters for compliant-only and since-a-date. Each mirrors the receiver's schema so it drops into your conditional-access rules.

Evidence your auditor verifies without you

Every decision proves which signed policy made it — checked offline.

Why it matters
For FedRAMP and CMMC, per-request provenance turns a policy from "claimed" into "evidenced." Your auditor pulls the signed bundle, verifies it offline, and reads the controls in force — without trusting Tether to vouch for itself. That's the difference between a story and proof.
What it does
Every decision carries the policy version that made it, recoverable as a signed bundle anyone can verify offline. One caveat: durable per-request retention depends on your SIEM forwarding, which is why the SIEM adapters ship in the same release.

"This isn't spyware."
Here's the part you can check yourself.

The fastest way to lose a room full of developers is to make this feel like surveillance. It doesn't, and nobody should have to take that on faith. Every claim below, a developer can check on their own machine.

  • · No root certificate on your machine. Tether doesn't install a corporate CA, so it can't decrypt your banking session, your personal email, or anything else outside the AI routes. Check your trust store — nothing of ours is in it.
  • · The proxy is loopback-only. It binds to 127.0.0.1 by default; widening it takes explicit operator config and emits a named startup warning. Run netstat and see for yourself.
  • · It doesn't read TLS-tunneled content. It classifies the destination and reads prompts only on the AI routes your org configured — not your general web traffic.
  • · Safe work is never ticketed. The overwhelming majority of prompts pass silently. Only a named risk or a genuinely ambiguous moment ever surfaces a decision — there's no manager watching your ordinary work.

The loopback binding and route-scoped inspection are in the technical brief →

Clipboard, downloads, external links —
visible and recorded now, enforced next.

TODAY: Advisory — visibility + audit NEXT: Hard enforcement with the managed VSCodium build
What you get in pilot today
  • · Visibility and audit on every workspace action. Clipboard, downloads, external links, screen capture, and coach mode all surface a decision and emit an event you can see.
  • · VS Code extension. Shipped — identity sync, agent inventory, and opt-in coverage for the terminals VS Code spawns.
  • · Cooperative-agent approvals. Agents that ask permission can route through the same just-in-time approval queue your operators already watch.
What's next
  • · Managed IDE build. A signed installer for macOS, Windows, and Linux turns the advisory workspace controls into hard enforcement.
  • · More editors. VS Code is shipped; Cursor and JetBrains are on the near-term roadmap.
  • · Durable evidence retention. Tamper-evident, long-horizon retention of every signed policy version, for teams that need full forensic history.

The exact state of each workspace control — what's enforcing versus advisory, and the roadmap behind it — is in the technical brief →

A risky moment, governed —
without filing a developer ticket.

When a moment genuinely needs a human, the developer doesn't open a ticket and wait a day. The action pauses, an operator gets the context, and a decision comes back in seconds. Safe work never triggers any of this.

The developer stays in flow. The risky action pauses in place rather than failing or filing a ticket. Approve, and they continue immediately — no context switch, no support queue.

The operator gets what they need to decide. Who, what, and the matched policy land in one console view. The default target is a five-minute decision window, tunable to your team.

It's auditable either way. Approve, deny, or let it time out — every outcome is recorded, and you choose the safe default when no one answers in time.

Cooperative agents use the same lane. An AI agent that asks permission before acting routes into the very same approval queue your operators already watch — one console, one workflow.

See the operator decide in seconds on the demo → The request-and-decide machinery is in the technical brief →

"What about Cursor?"

How much Tether sees depends on the tool. Here's each one, specifically.

For the CLI agents and editors your developers actually live in — Claude Code, Codex CLI, Aider, Zed, Continue — Tether reads the full prompt and response and enforces against it. That's the deep-visibility case, and it covers the tools doing the heavy lifting.

For tools with an opaque path — Copilot's chat, Cursor's default flow on unmanaged devices — Tether still ties the activity to a person and a vendor and can block the destination, but it doesn't read prompt content it can't see. And every decision records how the agent was identified — explicitly, inferred from headers, or unattributed — so the audit distinguishes solid attribution from a guess.

Bring the two tools your developers use most. In the walkthrough we'll show you exactly what Tether sees on each — full content, or attribution-only — and where the gaps are, before you commit to anything.

The full per-tool coverage matrix — architecture, best tier, what's seen, and the gap for each — is in the technical brief →

How we protect it → Security & trust →

Bring two tools.
We'll show you both tiers.

Bring the AI tool your developers use most and one you're considering. We'll show you what Tether sees on each — and what it doesn't.

Book a 30-min walkthrough ↗