Identity is not permission.
Authentication establishes who is calling. AIRCTRL separately checks account membership, roles, and permissions to determine what that identity may do.
Security & architecture
Your secrets stay yours.
Know the boundaries.
Client-side encryption for Vault. Explicit controls for Gateway. From the keys on your device to the checks at our API, understand what protects your data, who can read it, and where each guarantee ends.
Client-side Vault encryption
Fail-closed authorization
Tamper-evident audit trail
01The system shape
Separate surfaces.
Explicit trust boundaries.
Customer and staff access are separate. Requests pass through authenticated service boundaries, not direct browser access to the underlying data stores.
System boundariesSeparate identities. Explicit access.
Customer product
Your account and authorized tools.
Customer identityStaff console
Separate, authorized staff access.
Staff identityAIRCTRL service
Verify identity, account, and permission.
Authenticated boundaryData storage
Records and security history.
Service access onlyOperational state
Usage and request controls.
Service access onlyCustomer and staff credentials are not interchangeable. A signed-in identity still needs permission for the requested action.
Customer and staff stay separate.
Customer and staff identities use separate trust boundaries. A customer session does not grant staff access, and staff actions have their own authorization and audit controls.
02The zero-knowledge Vault
Encrypted before upload.
Unlocked by your keys.
Vault secret values are encrypted on your device. AIRCTRL stores ciphertext and wrapped keys, while authorized clients hold the keys needed to decrypt them.
The Vault key hierarchyCryptography runs in your client.
- Your passphrase
Entered and used locally.
Never sent to the API - Master key
Derived from your passphrase.
PBKDF2-HMAC-SHA256 - Vault key
Encrypted under the master key.
AES-256-GCM · AES-KW - Record data key
A separate key for each record.
Protected with AES-KW - Encrypted value
Ciphertext ready for storage.
AES-256-GCM
The server stores ciphertext and recipient wrappers. Changing a passphrase re-wraps key material without re-encrypting every record.
The client does the cryptography.
The browser, SDK, CLI, or local MCP process encrypts and decrypts record values. The Vault passphrase is used locally and is not an API credential.
The API stores encrypted values, encrypted private-key material, and recipient wrappers. Public keys let clients share without handing the server a usable Vault key.
Change the passphrase, not every secret.
The key hierarchy separates your passphrase from the keys that encrypt individual records. A passphrase change re-wraps key material rather than rewriting thousands of secret values.
Recovery and passphrase changes happen in the client. Your new passphrase is not sent to the service.
Encryption standards and the server boundary
- Passphrase derivation
- PBKDF2-HMAC-SHA256 derives key material locally from your passphrase.
- Vault key storage
- AES-256-GCM under the passphrase-derived master key.
- Per-record encryption
- A separate data encryption key protects each record with AES-256-GCM.
- Owner key wrapping
- AES-KW protects a record’s DEK under the Vault key.
- Recipient sharing
- X25519 sealed boxes protect key material for a recipient’s public key.
Vault decryption and recovery take place in authorized clients. The service stores encrypted material without the usable client-held keys needed to open it.
Read the records and secrets guide03Different data. Different guarantees.
A Vault stores.
A Gateway acts.
Zero knowledge describes who can decrypt a value. Retention describes how long data is kept. They are different questions, and the answer depends on which AIRCTRL feature you use.
Vault records: client-side encryption
Secret values are encrypted before upload. Authorized people and machines decrypt them in their own client or process.
AIRCTRL stores ciphertext and wrapped keys, without the usable keys required to open those values.
Use Vault when the value must remain outside the service operator’s decryption capability.
Gateway credentials: server-side encryption
The proxy needs a provider key to make upstream calls on your behalf. These keys are encrypted server-side and are not Vault records.
The server can decrypt provider credentials for upstream operations, so this model is not zero knowledge.
Use Gateway for model routing, access policies, rate limits, and spending controls.
What happens to an AI request?
Gateway documentationRequest contentRetention follows configured settings.
Provider credentialsServer-encrypted for proxy use.
Operational metadataUsage, access, and account records.
Review retention settings. Gateway processes AI requests on your behalf. Prompt and response retention depends on request-body logging and caching settings. Review those settings and your model provider’s policies before sending sensitive data. Zero-knowledge Vault storage does not make the proxy blind to the requests it handles.
Keep labels non-secret. Record names, tags, formats, rotation dates, authors, timestamps, and state are readable metadata. Encryption protects the secret value, not the fact that a record exists.
What is stored in each data category?
- Prompts & responsesConfiguration-dependent
- Gateway processes AI requests on your behalf. Prompt and response retention depends on request-body logging and caching settings. Review those settings and your model provider’s policies before sending sensitive data.
- Vault credentialsClient-side encryption
- Vault secret values are encrypted on your device. AIRCTRL stores ciphertext and wrapped keys, while authorized clients hold the keys needed to decrypt them.
- Gateway provider credentialsServer-side encryption
- Provider keys configured for the proxy are encrypted server-side. Gateway can decrypt them to make upstream requests. They are not zero-knowledge Vault records.
- Record metadataReadable by the service
- Names, tags, secret formats, rotation dates, authors, timestamps, and state support search and administration. Do not put a secret value in a record name or tag.
- Account & operational metadataKept to operate the service
- Account information, model and provider metadata, timestamps, usage, billing, and security records support access controls and operation. They are separate from prompt and response content.
06A verifiable audit trail
Each event links back.
Each link can be checked.
Cryptographically linked audit events make changes to recorded history detectable. Customer activity and internal staff actions have separate audit trails.
A linked security recordTamper-evident, not tamper-proof.
hash(n) = SHA-256(hash(n-1) + canonical_event(n))- Previous seal
The prior event’s recorded hash.
event n-1 - Recorded event
The action and its security context.
No decrypted Vault values - New seal
Link this event to the one before it.
SHA-256 - Verify the chain
Recompute and compare the links.
Customer and staff chains
New events extend the record. Verification checks its integrity; it does not claim that every action outside AIRCTRL can be observed.
Append-only application paths.
Normal application operations add events rather than rewrite existing history. Each new event is linked to the one before it so recorded integrity can be checked.
When identifying data must be removed, referenced rows can be pseudonymized so the security record retains its links.
Log the action, not the secret.
Security events record actions and their context, not decrypted Vault values. This helps teams review access without turning the audit trail into another copy of their secrets.
These controls provide tamper evidence, not an assurance that every action outside AIRCTRL can be observed.
Tamper-evident does not mean tamper-proof
Verification checks whether the recorded events still agree with their cryptographic links. It is a way to detect changes, not a promise that no privileged attacker could alter a system.
Audit integrity works alongside access controls and evidence preservation. This overview is not a live verification result or an independent security assessment.
07Hardening the entry points
Validate at the edge.
Fail closed by default.
The HTTP boundary is not only for signed-in people. Scheduled jobs, inbound webhooks, and AI traffic each have their own authentication and replay or usage controls.
- 01Protective headers
- HTTP security headers help restrict how browsers handle API responses and interact with the service.
- Safer response handling
- 02Input validation
- Requests are checked against the accepted shape and types before their contents are used.
- Validate before processing
- 03Origin restrictions
- Browser-origin policies allow intended clients rather than unrestricted cross-origin access.
- Explicit browser boundaries
- 04Usage controls
- Rate limits help constrain abuse. Gateway adds scoped usage and spending controls for routed model requests.
- Bounded access and usage
- 05Safe retries
- Supported write operations use duplicate-request protection to avoid repeating an action when a delivery is retried.
- Avoid duplicate side effects
Scheduled jobs
Automated tasks require service authentication. Missing security configuration is not treated as permission to run.
Inbound webhooks
Inbound event signatures are verified before the contents are trusted. Duplicate-delivery protection helps prevent repeated processing of the same event.
Gateway data plane
Gateway credentials are checked before upstream requests. Scoped rate and spending controls apply to the AI traffic routed through AIRCTRL.
Controls are not a blanket guarantee
Secure configuration, dependency maintenance, and validation are ongoing responsibilities. Describing a control does not certify every deployment or mean that software is free of vulnerabilities.
Review the product boundaries alongside the controls when evaluating AIRCTRL for your use case.
08Sessions and data lifecycle
Less exposure while open.
Deliberate actions when closing.
An unlocked client is part of the trust boundary. Session controls reduce that exposure, while deletion and privacy controls distinguish encrypted material, behavioral telemetry, and the security audit record.
Lock the unattended session.
Session locking and idle expiry reduce the exposure of an unattended Vault. Sign out or lock the session when you step away.
Locking clears the unlocked client’s key state. Service-side authorization remains authoritative for access to stored records.
Remove the stored key material.
Deletion controls include removing the key material needed to open encrypted data. Their effect depends on the scope of the deletion and any independently held keys.
Audit-linked rows are pseudonymized where needed. Deletion does not erase copies already exported to another device.
Analytics is a separate choice.
Opting out stops future behavioral telemetry and removes the user’s previously collected telemetry.
The security audit trail is deliberately separate. An analytics preference does not remove the evidence needed to review access and changes.
An unlocked device is part of the trust boundary
Authorized clients need access to decrypted values while you use them. Encryption at rest does not protect plaintext from hostile code running inside a compromised, unlocked client.
Keep your device, browser, extensions, and local tools trusted and up to date. Lock the Vault when it is not in use.
Cryptographic erasure depends on removal of the necessary key material. It does not undo earlier disclosures or replace controls for retained backups and independently held keys.
09The limits are part of the model
Document the controls.
Document the boundaries, too.
Understand what each protection covers, what it does not, and which choices remain yours. These boundaries matter when deciding where to put sensitive data.
- Project key rotationSeparate from access revocation
- Revoking project access does not automatically rotate shared encryption keys. Previously copied keys and values cannot be recalled. Rotate exposed credentials with their issuing service and review every remaining access grant.
- Gateway credential accessServer-side encryption
- Gateway can decrypt provider credentials to make upstream calls. Those credentials do not have Vault’s zero-knowledge guarantee. Evaluate this server-side trust boundary separately from client-side Vault encryption.
- Request retentionDepends on configuration
- Request-body logging and caching settings affect prompt and response retention. External model providers also have their own policies. Review both before sending sensitive content.
- Client and metadata exposurePart of the trust model
- Record metadata is readable, and decrypted values exist in authorized client memory. A compromised browser or an agent given plaintext remains outside what storage encryption can prevent.
- Security assessmentAn ongoing responsibility
- This overview is not an independent audit, a live vulnerability scan, or a claim of certification. Request current assessment materials for a review of your specific requirements.
This page is a public overview, not an independent certification or a live security assessment. Request current review materials for your evaluation.
10US hosting and infrastructure
Trusted infrastructure.
Specific compliance scope.
AIRCTRL is built on AWS, CoreWeave, and Crusoe, infrastructure providers with independently assessed SOC 2 controls for specified services.
AIRCTRL-managed infrastructure is hosted and managed in the United States.
External model and service destinations have their own residency, retention, and data-handling terms. Review the destination as well as the AIRCTRL configuration.
AWS
Amazon Web Services
AWS publishes SOC 2 reports and HITRUST CSF certification for specific in-scope services.
CoreWeave
AI cloud infrastructure
CoreWeave publishes SOC 2 Type II coverage for Bare Metal and CoreWeave Kubernetes Service.
Crusoe
AI cloud infrastructure
Crusoe Cloud has completed a SOC 2 Type II examination and provides assessment materials through its Trust Center.
Provider assurance. Our responsibility.
Provider reports do not constitute a SOC 2 attestation for AIRCTRL or TheoVex. Our application, configuration, and operations remain our responsibility.
Coverage depends on each provider’s listed services and assessment scope. The HITRUST reference applies to AWS’s in-scope services, not every provider. No HITRUST certification for AIRCTRL or TheoVex is claimed.
Amazon Web Services, AWS, and the Powered by AWS logo are trademarks of Amazon.com, Inc. or its affiliates. CoreWeave and Crusoe marks belong to their respective owners. Provider logos identify infrastructure used by AIRCTRL, not endorsement.
Developer documentation
Take the architecture into your code.
Authentication
Human tokens, service accounts, and verified account context.
Records and secrets
Client-side encryption, sharing, rotation, and local use.
AI gateways
Provider credentials, request settings, usage, and observability.
Developer workflows
Choose the right combination of dashboard, SDK, CLI, and MCP.
The questions
worth asking.
Reviewing AIRCTRL for your team? Bring your data flows, provider choices, and security requirements.
Does zero knowledge mean AIRCTRL stores nothing?
No. Vault stores encrypted secret values and wrapped keys. Record metadata, account data, usage, billing, and security records have separate purposes. Zero knowledge describes the service’s inability to decrypt Vault secret values without client-held keys, not the absence of stored data.
Is Gateway covered by the same zero-knowledge guarantee?
No. Gateway provider credentials are encrypted server-side because the proxy must use them for upstream calls. Gateway also handles request content, and optional body logging and caching affect retention. Review those settings and your destination provider’s policy.
Can a model see a secret returned by MCP?
Yes. A local MCP process may decrypt a value and return it as a tool result to the agent. Only authorize that operation when the agent may receive the secret. CLI child-process injection can start an application without returning its values as a model tool result. The application and its runtime must still be trusted.
Does removing access erase a secret somebody already copied?
No. Revocation stops the access covered by that grant; it cannot delete a copy from another device. Project access revocation does not automatically rotate shared encryption keys. Rotate an exposed credential with its issuing service, and review separate shares and ownership that may still grant access.
Do the provider assessments cover AIRCTRL or TheoVex?
No. Provider reports do not constitute a SOC 2 attestation for AIRCTRL or TheoVex. The linked reports cover the named infrastructure providers and their specified services, not our application. Review the applicable services, configuration, contracts, and current assessment materials.
Does the roadmap mean AIRCTRL is FedRAMP certified?
No. TheoVex’s long-term compliance roadmap includes pursuing FedRAMP certification for its cloud services. This is a future goal, not a current FedRAMP certification or authorization for AIRCTRL. FedRAMP applies to a defined cloud service offering, not a blanket company certification. We are not claiming a formal FedRAMP status or a completion date.
Keep building. Stay in control.Your next idea.
Your next idea.
A better foundation.
Your choice of agent. Your choice of model. One Gateway for the connections. One Vault for the secrets.
Or talk through your setup with us