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).
Cool solution, and kudos on investing in getting the compliance groundwork stuff sorted out early. I can't imagine that was cheap or easy. I'd think this is primarily interesting to the newer a&d companies, right? Or even companies who are looking at their first government project. That seems to me like where the value is. The usual suspects tend to already have people and policies in place for proper handling of sensitive info.
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.
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?
To build on this: a gateway controls where the model request goes, but with coding agents the data often leaves another way. A tool result can include file contents, and then the model can be steered into putting that data into a web fetch URL or a call to some third-party MCP server. That traffic never goes through the gateway, because it starts from the client machine. So the real boundary has to include an egress allowlist on the developer's machine or in its sandbox, not just the model endpoint. I'd be curious whether Consus ships a recommended client-side configuration, or treats that as the customer's job.
We had a lot of problems letting finding a balance giving technical coworkers acces to live data and AI tools. And there are multiple companies in this space that solve things in multiple ways, we happen to use https://gluondb.com which is what you describe plus BI.
Food for thought, tool and MCP calls run locally, but every request carries the tool list and every response carries the model's tool calls, both of which pass through you. You could strip non-approved tools from the request and block calls to them in the response, based on an org allowlist. That gives you org-approved MCP/tool calls without touching the dev's machine.
Great call. We already block certain tool schemas and flag URLs in tool-call arguments, and since we enforce org allowlists for models on every request, extending that to tools/MCP is a natural next step.
Interesting that the pitch is density: $0.37/month per sandbox implies a lot of them packed onto shared hardware. My sandbox experience is the malware kind: at Fortinet I ran NSS Labs testing on a sandbox engine, and a key question was whether results held as throughput tiers went up, with sample loss tracked per tier. Same question seems worth asking here: do isolation and agent performance hold at peak packing, not just average utilization?
How does ZDR work with requests that trip security measures in the model provider? Do the providers retain those requests for analysis or is that too guaranteed?
The infra providers call this "abuse monitoring" or "abuse detection" and we've worked with them to turn it off. We don't serve models like Fable that require it. We have one case remaining for OpenAI's GPT-5.x models in AWS. AWS's automated classifier can retain a flagged request for up to 30 days. Per AWS, that review is automated with no human access, the data stays in AWS GovCloud, and it's never shared with OpenAI. We are actively working to turn that off as well. Everything else is covered.
Correct. We have contractual agreements to ensure no data that passes through our platform will be used for model training purposes. In addition, we have in our contracts that we (Consus) will also not use any data for training purposes. We couldn't if we wanted to since we do not store any prompt data.
We've been focused on defense, so we haven't set up HIPAA (BAAs) yet. The underlying controls are essentially FedRAMP High, so it wouldn't be a big lift on our side. If you have a specific use case in mind, drop me a note at founders@consusindustries.co and we can talk more about it.
W.r.t observability: We don't use any third-party error tracker, APM, or queues. If any request fails, the client gets an error message that we write as opposed to the raw provider error. On our side, every log lives inside our boundary, and is written from a field allowlist (ids, model, token counts, status, latency). The JSON is purposely stripped away so any details in the request do not land in our logs.
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).
Cool solution, and kudos on investing in getting the compliance groundwork stuff sorted out early. I can't imagine that was cheap or easy. I'd think this is primarily interesting to the newer a&d companies, right? Or even companies who are looking at their first government project. That seems to me like where the value is. The usual suspects tend to already have people and policies in place for proper handling of sensitive info.
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.
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?
To build on this: a gateway controls where the model request goes, but with coding agents the data often leaves another way. A tool result can include file contents, and then the model can be steered into putting that data into a web fetch URL or a call to some third-party MCP server. That traffic never goes through the gateway, because it starts from the client machine. So the real boundary has to include an egress allowlist on the developer's machine or in its sandbox, not just the model endpoint. I'd be curious whether Consus ships a recommended client-side configuration, or treats that as the customer's job.
We had a lot of problems letting finding a balance giving technical coworkers acces to live data and AI tools. And there are multiple companies in this space that solve things in multiple ways, we happen to use https://gluondb.com which is what you describe plus BI.
Seems like a pretty crowded space.
We do give our customers guidance to make sure they are thinking about this properly. This typically happens during on-boarding.
We also built out pre-defined controls for common tools so they can click a button and not think about it.
Food for thought, tool and MCP calls run locally, but every request carries the tool list and every response carries the model's tool calls, both of which pass through you. You could strip non-approved tools from the request and block calls to them in the response, based on an org allowlist. That gives you org-approved MCP/tool calls without touching the dev's machine.
Great call. We already block certain tool schemas and flag URLs in tool-call arguments, and since we enforce org allowlists for models on every request, extending that to tools/MCP is a natural next step.
Interesting that the pitch is density: $0.37/month per sandbox implies a lot of them packed onto shared hardware. My sandbox experience is the malware kind: at Fortinet I ran NSS Labs testing on a sandbox engine, and a key question was whether results held as throughput tiers went up, with sample loss tracked per tier. Same question seems worth asking here: do isolation and agent performance hold at peak packing, not just average utilization?
How does ZDR work with requests that trip security measures in the model provider? Do the providers retain those requests for analysis or is that too guaranteed?
The infra providers call this "abuse monitoring" or "abuse detection" and we've worked with them to turn it off. We don't serve models like Fable that require it. We have one case remaining for OpenAI's GPT-5.x models in AWS. AWS's automated classifier can retain a flagged request for up to 30 days. Per AWS, that review is automated with no human access, the data stays in AWS GovCloud, and it's never shared with OpenAI. We are actively working to turn that off as well. Everything else is covered.
Does it offer a self-hosted or air-gapped option for customers who cannot send data to any outside service?
I love this. Will this guarantee that proprietary/ sensitive/ CUI data won't leak to model training or other parties?
Correct. We have contractual agreements to ensure no data that passes through our platform will be used for model training purposes. In addition, we have in our contracts that we (Consus) will also not use any data for training purposes. We couldn't if we wanted to since we do not store any prompt data.
Does this work with HIPAA data ?
We've been focused on defense, so we haven't set up HIPAA (BAAs) yet. The underlying controls are essentially FedRAMP High, so it wouldn't be a big lift on our side. If you have a specific use case in mind, drop me a note at founders@consusindustries.co and we can talk more about it.
[dead]
[dead]
[flagged]
Glad you like the compliance suffix.
W.r.t observability: We don't use any third-party error tracker, APM, or queues. If any request fails, the client gets an error message that we write as opposed to the raw provider error. On our side, every log lives inside our boundary, and is written from a field allowlist (ids, model, token counts, status, latency). The JSON is purposely stripped away so any details in the request do not land in our logs.
What is this AI slop even supposed to mean? Did the company write this?