THE MILGRAM PLATFORM
Inspect the traffic, connect the session, and apply the policy. One proxy brings security visibility and inference optimization to supported AI integrations.
THE CONTROL POINT
An LLM firewall inspects traffic between AI applications and model providers, applying security controls where model context passes.
Milgram combines that firewall with session visibility and inference optimization. It inspects requests, responses, tool calls, tool results, and model reasoning when the provider exposes it. It reconstructs multi-turn sessions so an investigation can follow behavior across an agent’s workflow.
Applications route supported provider traffic through Milgram. Security teams use the dashboard or a customer-controlled AI connected through MCP to examine findings. Policies govern supported traffic paths; deterministic compression reduces the context sent onward.
Coverage begins with traffic routed through the proxy. Tool execution, network access, and infrastructure permissions remain the responsibility of the application and its surrounding controls.
THREE COMPLEMENTARY LAYERS
No single detection method sees every attack. Milgram combines mechanisms with different strengths and exposes the evidence for review.
Inspect individual messages for known attack techniques and their variations: prompt injection, credential leakage, obfuscation, unsafe agent behavior, and other malicious payloads.
Rules provide concrete matches that a detection engineer can investigate, tune, and test against benign examples.
Combine signals across messages to surface task drift, unauthorized coordination, and gradual escalation that may be hard to interpret in isolation.
Session correlation connects evidence across messages. On supported live request paths, correlation policies can block a request before it reaches the provider. Historical replay and rescan findings support investigation.
A lightweight classifier supplements deterministic rules for behavior that does not match a known pattern exactly.
Organization-specific tuning uses reviewed signals and false-positive corrections. Representative validation remains essential as the model changes.
POLICY BY CONTEXT
| Mode | Behavior | Practical use |
|---|---|---|
| Shadow | Allow traffic while recording detections. | Establish a baseline and review ambiguous findings before introducing enforcement. |
| Block | Stop a supported request or session when a configured security policy triggers. | Enforce a validated boundary for high-confidence threats. |
| Mask | Replace supported sensitive spans with placeholders. | Reduce exposure of PII, credentials, and authentication tokens to model providers. |
Policies can vary by detection type, severity, user, or use case. An organization can mask PII, block selected threats, and monitor lower-confidence findings in shadow mode.
No. Provider safety behavior, application authorization, sandboxing, and network controls address different parts of the risk. Milgram adds an inspection and policy boundary around the AI traffic your organization routes through it.
It can inspect the tool calls and results present in proxied traffic and reconstruct their session context. Actions outside that traffic path, omitted tool outputs, or reasoning not exposed by a provider are not automatically visible.
Choose one representative workflow and route it through Milgram in shadow mode. Review both malicious examples and normal work, then test the supported enforcement paths before widening coverage. The evaluation guide provides a practical sequence.
INVITE-ONLY BETA
Tell us what you use, what you need to protect, and where Milgram would run.
