FAQ
What is CodyRouter?
CodyRouter is a unified LLM access layer for applications, AI coding tools, and upstream model providers. You can use one API key, one base URL, and a consistent model interface while managing usage, billing, activity, and request troubleshooting from the Dashboard.
CodyRouter is not just a basic proxy that forwards requests to a model. It is designed to be a trusted routing layer between your application and model providers: unified access, unified billing, unified observability, and stronger privacy/model-authenticity guarantees through the Enclave endpoint when needed.
How is CodyRouter different from other AI aggregation gateways?
Many AI aggregation gateways focus on calling multiple models through one interface, with unified API formats, model lists, billing, and availability. CodyRouter adds a stronger trust layer on top of those basics: users should not have to rely only on provider statements such as “we do not read your data” or “we do not swap your model.”
CodyRouter focuses on:
- Trusted secure path: The Enclave endpoint processes sensitive requests inside a hardware-isolated execution environment, so the routing layer is designed not to read request content.
- Model authenticity: The routing layer is designed to reduce the risk of hidden model substitution, downgrading, or “watered-down” responses.
- Traceable request path: Each request carries request / trace information so issues can be located across the edge gateway, routing layer, Enclave endpoint, upstream provider, or client configuration.
- Business and enterprise use cases: CodyRouter is built for production workflows, teams, enterprise procurement, and users who care about privacy, compliance, and model quality, not only the lowest possible price.
What is end-to-end encryption?
Strictly speaking, the CodyRouter Enclave endpoint is not end-to-end encryption in the same sense as a private messaging app, because the request still needs to be unpacked, transformed, and forwarded to the model provider inside a protected execution environment.
The practical explanation is: your request is put into a sealed box. The middle routing layer can forward the box, but cannot open it and inspect the contents. Only the protected secure execution environment and the final model provider participate in the actual processing.
The Enclave endpoint is implemented on top of AWS Nitro Enclaves. A simple way to understand it is as a “secure processing box” provided by the AWS Nitro System: the outer CodyRouter services can send requests into the box and return the result, but they cannot enter the box like a normal application server to inspect the data being processed.
In the Enclave endpoint path, the critical connection handling from your client to CodyRouter’s secure execution environment, and from that secure environment to the upstream model provider, happens inside the Nitro Enclave protected boundary. The normal control plane, logging system, operators, and edge proxies should only see required metadata such as request status, latency, billing information, and trace IDs, not your prompt, code, or full model response body.
The point is not “please trust the CodyRouter operator.” The point is to reduce the trust boundary to two more verifiable assumptions: first, the sensitive code path you are using is actually running inside a trusted execution environment such as AWS Nitro Enclave; second, even AWS as the cloud provider cannot bypass the trusted boundary created by Nitro Enclaves through the Nitro Hypervisor, vCPU/memory isolation, and cryptographic attestation to directly read or tamper with runtime data inside the enclave.
For product communication, we may describe this as “near end-to-end encryption,” “the middle layer cannot open the message,” or “hardware-level protection.” The more precise technical point is: decryption, transformation, and upstream forwarding of sensitive content are constrained to a trusted execution boundary.
What is AWS Nitro Enclaves?
AWS Nitro Enclaves is a trusted execution environment technology for creating isolated execution environments, called enclaves, from virtual machines. In practical terms, it creates a smaller, more locked-down security room next to a cloud server for running the most sensitive code.
According to AWS documentation, enclaves are separate, hardened, and highly constrained virtual machines. They provide only secure local socket connectivity with their parent instance, and they have no persistent storage, interactive access, or external networking. Users cannot SSH into an enclave, and the data and applications inside the enclave cannot be accessed by the processes, applications, or root/admin users of the parent instance.
Nitro Enclaves uses Nitro Hypervisor technology to isolate the enclave’s vCPUs and memory from the parent virtual machine. It also supports cryptographic attestation, which allows you to verify the enclave’s identity and ensure that only authorized code is running inside it. AWS positions Nitro Enclaves for highly sensitive data processing, including personally identifiable information, healthcare, financial, and intellectual property data.
CodyRouter Enclave endpoint uses Nitro Enclave to run the sensitive request-processing path. The outer services send traffic into the enclave, receive the result, record necessary metadata, and handle billing. Inside the enclave, CodyRouter processes the user request body, performs required format transformations, and connects to the upstream model provider.
The benefit is that users do not need to place full trust in any platform operator. What users need to verify is that CodyRouter’s sensitive processing code runs inside AWS Nitro Enclave, and that the hardware isolation and attestation properties of Nitro Enclaves hold as designed. If those two conditions hold, CodyRouter / AWS operators and administrators cannot read the request and response bodies inside the enclave.
Official references:
How do we guarantee no model switching and no data storage?
CodyRouter addresses two trust problems at the architecture level: whether the model is authentic, and whether sensitive data is retained by the intermediary.
Model routing is recorded and auditable. CodyRouter’s routing layer selects the target model based on the user request, model configuration, and backend routing policy, while recording a traceable request path. Users do not need to rely only on a provider statement that the model was not switched; they can use call records and proof material to check whether the request went through the expected path.
Upstream HTTPS domains are restricted inside the Enclave. When the Enclave initiates an upstream HTTPS request, it only connects to allowed model-service domains. If the target domain is not on the allowlist, the Enclave will not initiate the request. This reduces the risk of routing a request to an unknown service, an unexpected provider, or a disguised model source.
Enclave Proof can be verified offline. Users can export the Enclave Proof for a specific call and verify it independently with our offline verifier at https://codyrouter.com/enclave-verify. The verifier checks whether the request was processed inside the Enclave, whether the proof was signed by trusted code, and whether the attestation document, PCR values, request hash, and response hash are consistent. This verification does not rely on a unilateral statement from the CodyRouter operator.
Billing and troubleshooting records do not contain content. CodyRouter still needs to keep necessary billing, risk-control, and troubleshooting records. Those records do not contain the user prompt, source code, or full response content. The goal of the Enclave endpoint is not to make the system record nothing at all, but to prevent sensitive content from being read or retained by the intermediary layer.
Can Enclave code be provided for verification?
- Verification material can be provided. CodyRouter can provide published source code and Enclave code to enterprise users for verification purposes, so their security teams can review whether the logic running inside the Enclave, the proof material, and the platform statements are consistent.
- CodyRouter Transparency Program is available. We provide a “CodyRouter Transparency Program” for enterprise users. After joining the program, enterprise users can receive real-time information about CodyRouter production deployments, including Enclave-related versions, deployment changes, and verification material updates.
- Upgrades can be re-verified. If the Enclave code is upgraded or replaced, users do not need to rely only on a platform statement that “the system was upgraded and is still safe.” Each Enclave version should produce new verifiable proof material, including published source code, an attestation document, PCR values, signatures, and version identifiers.
- The verification target is consistency. An enterprise security team can compare the new source code, build artifacts, and the PCR / attestation information in Enclave Proof to confirm that the upgraded logic still satisfies the agreed security requirements, such as connecting only to allowed upstream domains, not recording request bodies, not exposing sensitive content, and not bypassing the proof flow.
- Contact support to request access. To request access and discuss the delivery scope and verification process, contact our support team at support@codyrouter.com.