Your work stays yours.

Credentials are encrypted before persistence. Security-sensitive actions are logged. Product data stays on controlled nodes unless you direct a tool or provider connection to use it. This is an architecture posture, not just policy.

Strong encryption. Always.

01
At rest

AES-256-GCM at rest.

API keys and credentials are encrypted with AES-256-GCM before they touch disk. Each value is encrypted with a key derived from the installation. They never appear in logs, session output, or API responses. The encrypted form is the only form ever persisted.

02
In transit

Credentials never travel in plaintext.

Each delivery uses a separate ECDH P-256 key exchange. A shared secret is derived, used once, and discarded. Nothing sensitive is transmitted without end-to-end encryption between nodes. The wire carries ciphertext. The plaintext never leaves the source node.

03
Certificates

ECDSA P-256 certificates.

Every node gets a unique certificate signed by the installation’s own certificate authority. Mutual TLS is enforced on every peer connection. There is no plaintext fallback. Connections that cannot be authenticated are refused before any data is exchanged.

No one gets in who should not be there.

04
Mutual TLS

mTLS on every peer connection.

Every node-to-node connection requires both sides to present a valid certificate. Authentication is mutual. The connecting node and the receiving node each verify the other. This happens at the transport layer before any application-level request is processed.

05
Permissions

Default deny.

Every permission starts closed. Access must be explicitly granted through a rule. There are no wildcard permissions. If a request does not match an explicit allow, it is refused. This applies to agent actions, file operations, and API calls without exception.

06
Rotation

Credential rotation built in.

Credentials are versioned. Rotation is a first-class operation, not an afterthought. The previous version remains valid during the rollover window so nothing breaks mid-operation. Subscribers receive the new value over the same encrypted channel automatically.

Every node is known. Sensitive actions are logged.

07
Isolation

Data stays on your node.

The product is designed around controlled nodes rather than a default central credential store. Your product data lives on the nodes you control, while account, billing, support, and service metadata are handled by Gravient as described in the Privacy Policy.

08
Audit log

Security events are recorded.

Tool calls, session starts, credential access, and permission changes are logged with timestamps and session IDs where the platform control layer can observe them. The audit trail is designed to support incident review, customer evidence, and enterprise governance.

09
Relay

Your relay sees nothing.

When nodes connect over the internet, traffic routes through the bridge relay. The relay forwards encrypted packets without decoding them. End-to-end encryption means the relay cannot read the content of any message it carries.

10
Secrets

Secrets are redacted at the boundary.

Sensitive values are stripped before they enter logs, evidence stores, or the session record. The system cannot accidentally leak a credential because it never stores cleartext at the boundary. Redaction happens before any persistence.

Built with SOC 2 in mind.

We are not yet SOC 2 certified. But the five trust service criteria shaped how this platform was designed from the ground up: security, availability, processing integrity, confidentiality, and privacy.

The control set is being prepared for audit. The pathway is open. Prospective enterprise customers can request our current security posture documentation.

Certification pathway in progress

Something to report?

Email security@greatvibe.ai and we’ll get back to you.