Works with what you run

Zetna™ fits the systems you already have

Your agents, your identity provider, your SIEM, your network and your hardware stay yours. Zetna connects to them by open standards where one exists.

Agents and their tools

• Claude Code, MCP clients and Hermes

  A consequential tool call waits for the person who owns the agent, and the answer is a receipt like any other.

  Each adapter is tested against recorded traffic. None has run in the real client.

• Sandbox policy approvals

  A sandbox's request to widen what an agent may reach waits for that person's touch, and it widens only the rule they saw.

  It is written for OpenShell's policy approvals and has run only against stand-ins.

Identity

• Your identity provider's token for an agent

  An agent's signed token from your identity provider is evidence once, when the agent is issued. After that the agent signs every call with its own key, and any bearer token is refused at every door.

  The provider's key is pinned, and the server never calls the provider.

• A company login at enrolment

  The server accepts a company login, or a PIV card, as evidence when a person enrols. The enrolment page does not fetch the login itself.

• A private name per service

  Each service knows a person under a private name of its own, so two services can't match them.

• Login bridge and directory

  A login bridge that checks the provider's signed tokens, and a SCIM endpoint for your directory, run in our first implementation.

Evidence

• Security events to your SIEM

  Security events go out as content-free OCSF events that your SIEM pulls from the server.

• Signals from your security tools

  A signal from one of your pinned security tools can only restrict an agent, never widen what it may do.

• Evidence packs for an examiner

  Receipts sit in an append-only log with signed checkpoints and proofs of inclusion. An examiner holding a grant two of the organisation's officers approved takes a range of it and checks it offline, and the log records who audited which range.

• Witnesses

  Witnesses co-sign the log's checkpoints in open formats, and an examiner counts how many distinct operators' witnesses signed.

Network

• Nothing leaves unless it is declared

  Every outbound connection passes one exit that refuses any destination you did not declare, and each refusal leaves a receipt.

• Network admission over 802.1X

  Your network access control can ask whether a device's key is still good. It has not run on a customer's network.

• Kernel network policy

  The exit's rules can be written out as kernel network policy for a cluster. It has not run on a customer's cluster.

Hardware

• The agent's key

  Each agent's key is created in hardware (a TPM chip or the Secure Enclave) and can't be copied off the machine; it signs every request.

  On a Linux server the TPM 2.0 chip also proves the key lives there. A service can require a hardware key, and every receipt of an agent's act records where its key lives.

• The approver's key

  The person's approval is a signature from a FIDO2 security key, or from Touch ID on the Mac the server runs on. A synced passkey is refused.

  The Touch ID key is not attested.

• Confidential computing

  A watch halts only the machine whose attestation falls below its floor. The checks run against stand-ins, not on confidential hardware.

• SIM for mobile and connected devices

  For mobile networks and their operators, a SIM-based number check and a SIM-swap signal can feed a credential decision.

  Those connectors are built in our first implementation and have not run against a live network.

A product named on this page is one an adapter is written for, not an endorsement. If you want to know how Zetna meets a particular product, write to us.