news.ycombinator.com

Launch HN: Consus (YC F24) – LLM gateway for companies handling sensitive data

ericmags · 36 points · 22 comments · 13 ต.ค.

Hey Hacker News! I'm Eric, the founder of Consus. We route all AI requests to ITAR restricted and controlled unclassified information (CUI) compliant infrastructure. Consus itself satisfies ITAR restrictions, and we recently completed our FedRAMP equivalency audit against the 410 FedRAMP High controls. FedRAMP High is the U.S. government’s strictest security baseline for cloud services handling sensitive unclassified data. A breach of this data could cause severe or catastrophic harm. Achieving FedRAMP equivalency, or authorization, is required before processing CUI information. Demo: https://youtu.be/6MYxJe6P4oY Aerospace and defense is experiencing rapid growth. Unfortunately, most companies are struggling to use AI because of necessary data protections & compliance risk. These companies can move even faster if they could use the AI tools that most other industries take for granted. I spent most of my career prior to Consus in aerospace & defense. I launched national security payloads at SpaceX, and was an early employee at Castelion. I’ve watched first hand how compliance red-tape makes it difficult for companies to adopt new technologies and trust vendors that touch their sensitive data. For example, I worked with a satellite manufacturer that doesn’t allow any AI tools, even for non-sensitive work. Even as AI has become extremely useful over the past 9-12 months, I was surprised by how many aerospace & defense companies refused to touch it. They could see how it could be helpful, but they were scared about model providers training on their data, violating an ITAR rule, or risk losing new business because of a failed cyber assessment. These are all rational fears. There were a lot of ways to solve some/all of these problems, but we focused on building a compliant AI inference layer that can "plug" into any AI tool or workflow. Just as OpenRouter integrates with most tools, Consus can connect to tools like ChatGPT or Claude, open source tools including the Pi coding agent or Open WebUI, or integrate with applications built and maintained by individual organizations. Almost no aerospace & defense company lives in all three major GovClouds (AWS, Azure, Google). When I mapped where frontier models can legally run for ITAR and CUI work, each provider had some subset of models, and each model achieved varying levels of compliance. Our customers don’t think in terms of cloud providers. They think about the data controls they require, and the model they want to use. That is why we built the compliance suffix. Under the hood, every request hits a single OpenAI-compatible endpoint, where keys are verified and policy is enforced before anything touches inference. Every model name must carry a compliance suffix, such as gpt-5.6-sol:fedramp-high or claude-opus-5-5:itar, and any bare model name is rejected. We never proxy to the standard commercial endpoints. Our customers are also able to build an allowlist of models, and assign spend & model restrictions to individual users in the organization. This is all handled through our Consus Portal where teams can manage spend, keys, and policies. A typical question we hear is why not just use Bedrock in AWS GovCloud or Azure Government directly. For small teams, just getting access to these platforms is difficult. For larger organizations, GovCloud lets you inherit some but not all of the controls needed to handle sensitive data. Also, models are split across providers: GPT-5.6 Sol is only available in Azure Government, while Claude Opus 5.5 is served through Bedrock in AWS GovCloud. If you want both, you are standing up and securing two separate government cloud environments. We run all of them behind one endpoint so customers don’t have to pick a cloud, and we handle the compliance work for each one. Given the data sensitivities, Consus does not store any customer data at rest. All prompts and completions stay in memory only for the length of the request and are never logged or written to disk. Zero data retention is strictly enforced both on ourselves and the infrastructure/model providers. We do keep metadata on each request and response for billing and audit purposes. Consus is not self-serve by design. ITAR requires us to know exactly who is on the other end of every key, so we verify every organization and put a contract in place before issuing API keys. We charge our customers a compliance fee starting at $40/mo/seat plus AI tokens at cost. We are actively serving customers, and would love any feedback from security experts, or developers/engineers working in highly regulated industries! References: API Documentation: https://gateway.consus.io/overview Security & Architecture: https://gateway.consus.io/security Compliance Details: https://consus.io/compliance

Comments

5 preview comments · loading full thread
ffseika0304เมื่อวาน

The storage-vs-egress split is where we landed after learning this the hard way. On the storage side we mask aggressively before anything is written (keys, intranet paths, phone numbers - better over-masked than leaky). On the egress side, raw bytes go upstream, and making egress masking opt-in per backend is the line we're moving to: untrusted upstreams get scrubbed, trusted paid backends get raw. The reason egress masking isn't just "do it everywhere" is coding traffic. A phone number inside a test fixture, an intranet IP inside a config file being edited - mask those and the model faithfully produces wrong edits. So the egress pattern set has to be narrower than the storage set (identifiers yes, code-shaped content no), and the switch has to be per backend, because "how much do you trust this upstream" is not one answer across a pool. Curious how you draw that line for coding agents - is sensitive-data traffic ever routed through coding workloads in your deployments, or do you treat those as separate compliance domains?

popkoren13 ต.ค.

Compliance at the gateway is necessary, but the apps those teams deploy still need the same skepticism on the other side of the fence. Auth bypasses, open storage and loose table rules do not show up in a FedRAMP checklist the way a missing control on the model path does. What has helped on small stacks is hitting the live URL as an anonymous visitor and as a second user. I built https://rowly.me to run that pass on AI-built apps automatically (sign-in, APIs, storage, database rules).

bitweis18 ต.ค.

Routing requests to compliant infrastructure covers where the model runs. With ITAR there is still the question of who inside the company gets to see the answer. Export rules apply to foreign persons, including employees working in the US (the deemed export case). So if an agent can pull controlled technical data through a tool call or a retrieval step, a non-US-person engineer who asks the right question gets it back, whichever endpoint served the request. Do you pass user attributes like US-person status or program access through the gateway, so retrieval and tool calls can be filtered per request? Or is that expected to live in each customer's own systems? I work at Permit, which builds authorization tooling, so this is the part I always end up asking about.

projectescape13 ต.ค.

This is great, question though, since you support coding agents like Claude Code and Codex, they run MCP servers, plugins, web search/fetch and their own telemetry from the dev's machine. Do you give customers guidance or controls for that side, or is it out of scope for the gateway?

christopheromar14 ต.ค.

These are some pretty significant compliance claims, especially around ITAR, CUI, and FedRAMP High equivalency. I think the technology sounds interesting, but I'd like to understand what's actually happening behind the scenes before taking those claims at face value. A few things I'd be curious about: - *ITAR compliance:* What does that mean in practice for Consus? Are there specific controls around personnel access, data residency, subcontractors, and handling export-controlled information? - *FedRAMP equivalency:* Was there an independent assessment covering all 410 FedRAMP High controls, or is this based on internal control mapping? Also, is there any publicly available documentation showing the assessment scope or authorization status? - *Data handling:* Where do prompts and responses go? Are they stored, and if so, for how long? Can customers disable retention? I'd also be interested in how logging works and whether downstream model providers can retain data for training. - *Customer isolation:* Are customers running in separate environments with dedicated encryption keys, or is isolation handled logically within shared infrastructure? - *Security enforcement:* How does the system handle prompt injection or attempts to generate restricted technical information? Is there an additional security layer beyond the model itself, and can customers audit those decisions? - *Encryption and key management:* Who manages the encryption keys, how often are they rotated, and what safeguards prevent unauthorized access? I understand that not every security detail can be made public, but even a high-level explanation of the assessment scope, control coverage, and how data moves through the system would help. There's definitely value in making AI accessible for regulated environments. I just think the distinction between claiming compliance and demonstrating how it's enforced matters a lot, especially for organizations dealing with sensitive information. Would be interested to hear how the team approaches these challenges.