Key concepts

Where things live

Address	What it serves
https://console.milgram.dev	The console: sessions, detections, keys, policies, your organization
https://api.milgram.dev/v1/proxy/<provider>	The proxy, one path per model provider (how it works)
https://api.milgram.dev/v1/mcp	The MCP server for your AI agents (MCP)
https://scanner.milgram.dev/v1	The API of Milgram’s model, nam-shub (overview)

Three credentials

Each surface has a credential of its own, and none is accepted in place of another.

Credential	Looks like	Used for	Where you get it
API key	mlg_…	The proxy	Console, Agents (API keys)
Scanner key	mgs_…	The model’s API	Console, Scanner (overview)
OAuth sign-in	none to copy	The MCP server	Your MCP client signs you in through the browser (MCP)

Scanner keys are shown once, when they are created; API keys stay available to their owner on the key’s page. Every key belongs to your organization and to the member who owns it, and stops working when it is revoked, when it expires, or when its owner leaves the organization or is deactivated.

Verdicts

Every scanned request gets a verdict.

• Flagged is the decision: something was found that counts.
• Severity describes the most serious finding: informational, low, medium, high or critical, or none when nothing was found. An informational finding (an email address in a prompt, say) is recorded and reported but never flags a request on its own.
• Categories say what was found, with a one-sentence description and, where they apply, the OWASP Top 10 for LLM applications and MITRE ATLAS references of the finding.

Categories

Category	What it means
instruction_override	An instruction to ignore or replace the model’s own instructions
system_prompt_extraction	An attempt to make the model reveal its instructions
indirect_injection	Instructions planted in content the model reads: a document, a web page, a tool result
role_hijack	An attempt to give the model another persona or role
virtualization	A pretend environment (a simulation, a terminal, an alternative AI) meant to lift the model’s rules
fictional_framing	A request dressed up as fiction, research or a hypothetical to get past the model’s rules
refusal_suppression	Instructions that forbid the model to refuse or to add warnings
policy_puppetry	Text that imitates a policy, configuration or system message to override the model’s rules
many_shot	Fabricated dialogue or prefilled answers meant to steer the model by example
payload_splitting	An attack split into pieces for the model to reassemble
encoding_obfuscation	Content hidden by encoding or transformation, such as base64, ciphers or leetspeak
unicode_smuggling	Invisible or look-alike characters that hide or disguise text
low_resource_language	An attack written in a language chosen to slip past safeguards
adversarial_suffix	Machine-generated strings appended to a prompt to break the model’s safeguards
behavior_manipulation	Instructions that quietly change what the model says or does: adding attacker text to an answer, steering it covertly, suppressing information
tool_agent_abuse	An agent’s tool call or action that abuses its tools or its environment
data_leak	Secrets, credentials or personal data in the traffic
harmful_content	Content that is harmful in itself
multi_turn	An attack spread across the turns of a conversation, found across its messages or in a message that sets one up
prompt_attack	Prompt injection, jailbreak, task drift or other malicious activity not covered by a more specific category

New categories can appear as detection improves: treat an unknown id as valid.

Sessions

The proxy groups traffic into sessions: the turns of one conversation, or of one agent’s run, in order, with their tool calls and tool results. A client that resends its history on every turn continues the same session. To name a session yourself, send the X-Milgram-Session header with the proxy request.

Policy actions

What happens to flagged traffic is set per API key: by the key’s default action while no policy is attached to it, and by its attached policies once one is. A key’s default action is shadow, log or block; policies can also mask, or turn a finding off.

Action	What happens
shadow	Everything is forwarded. Findings are recorded and reported in the X-Milgram-Verdict response header. The safe way to see what is found before enforcing.
log	As shadow; the finding is recorded for audit only.
mask	The matched content is replaced with a placeholder, in the request before it is forwarded and in the response before it is delivered (streamed responses are held until complete). A finding that cannot be located falls back to blocking. Policies only.
block	A flagged request is refused with 403 and never reaches the provider.
off	The finding is ignored: nothing is recorded or enforced.

When several policies apply, the most restrictive action wins: block, then mask, shadow, log, off.