LexLint.ioBeta

Know the law your code answers to.

The safeguards map

The tools that check and limit software and agents

The tools that check and limit software and the AI agents built on it, placed by what they inspect, how they run, where they enforce a limit, and what they do when something goes wrong. Every placement is sourced and dated. Placement is our reading of the product's own documentation; no publisher has reviewed or endorsed it. Nothing here says a product makes anyone compliant.

Rows
Filters

1. Review

What is wrong with it before it runs? Its leaves split by what is inspected.

1.1 Code and dependencies

Source, dependencies, licenses, secrets, infrastructure as code, model files.

In the Legal Handbook: What the law makes you constrain.

Listed: Eclipse SW360antenna, OpenDataology, OWASP Noir, S2C2F attestation schema and tool.

1.2 Agent configuration and declarations

What the agent says it is and can do: AGENTS.md, MCP manifests and tool descriptions, skills, A2A agent cards.

In the Legal Handbook: What the law makes you constrain.

No mapped entry in the seed.

1.3 Websites and published surfaces

A live site read but not exercised: trackers, consent banners, policy pages, security headers, accessibility.

In the Legal Handbook: What the law makes you constrain.

No mapped entry in the seed.

1.4 Product descriptions

What the owner declares about the product: its activities, markets, data, users.

In the Legal Handbook: What the law makes you constrain.

2. Testing

What goes wrong when we exercise it? Its leaves split by how it is run.

2.1 Tester-run

A person drives it, interactively or from a CLI, and reads the result.

In the Legal Handbook: What the law makes you constrain.

Listed: FuzzingBrain, Intersectional Fairness (ISF), ZAP (Zed Attack Proxy).

2.2 CI-integrated

Runs unattended on every change and can fail a build.

In the Legal Handbook: What the law makes you constrain.

3. Runtime

What stops it while it is in use? Its leaves split by where the limit is enforced.

3.1 Execution sandboxes

Execution sandbox: the box the agent runs in; it can touch only what the box allows. Never the regulatory kind.

In the Legal Handbook: How a gateway takes in legal constraint data.

3.2 Agent harnesses

Agent harness: inside the agent's own loop; permission modes, approval prompts, hooks. Never the evaluation kind.

The glossary entry. In the Legal Handbook: How a gateway takes in legal constraint data.

Listed: Continue, CrewAI, Cursor, GitHub Copilot cloud agent and CLI, Harness², LangGraph, LlamaIndex agents, Microsoft Agent Governance Toolkit, OpenAI Agents SDK, OpenHands, Sondera Coding Agent Hooks, Windsurf.

3.3 Gateways

Gateway: on the request path between the agent and its models, tools and other agents. A policy enforcement point.

The glossary entry. In the Legal Handbook: How a gateway takes in legal constraint data.

Listed: Amazon Bedrock AgentCore Gateway, Azure API Management AI gateway, Boomi MCP Gateway, Cloudflare MCP server portals, Docker MCP Gateway, Google Agent Gateway, Gravitee Agent Management, IBM API Connect AI Gateway, Lasso MCP Gateway, Lunar MCPX, MintMCP, MuleSoft Omni Gateway, Obot, Operant MCP Gateway, Portkey AI Gateway, Runlayer, ServiceNow AI Gateway, Tyk AI Studio, WitnessAI.

3.4 Guardrails

Guardrail: content and behavior classifiers a harness or gateway calls; they decide, something else enforces.

The glossary entry. In the Legal Handbook: How a gateway takes in legal constraint data.

Listed: Cisco AI Defense.

3.5 Policy engines

Policy engine: the decision point. Evaluates a policy and returns allow, deny or escalate.

The glossary entry. In the Legal Handbook: How a gateway takes in legal constraint data.

3.6 Identity and authorization

Who the agent is and what it is allowed to reach.

The glossary entry. In the Legal Handbook: How a gateway takes in legal constraint data.

  • Agent Name Service, Agent Name Service project
  • AGNTCY, Linux Foundation
  • Athenz, Cloud Native Computing Foundation
  • Keycloak, Cloud Native Computing Foundation
  • OpenFGA, Cloud Native Computing Foundation
  • Paralus, Cloud Native Computing Foundation
  • SPIRE, Cloud Native Computing Foundation
  • Tokenetes, Cloud Native Computing Foundation

Listed: Cartography, Jentic One.

3.7 Admission and owner settings

Decided once, before the first call: what may be installed, deployed or used. The per-deployment gate.

In the Legal Handbook: How a gateway takes in legal constraint data.

Listed: Observal.

3.8 Record-keeping

Records what ran. It does not constrain; the law places it on the system in operation (AI Act Art. 12).

The glossary entry. In the Legal Handbook: What a tamper-proof log still cannot tell you.

4. Incidents

What happens when it goes wrong anyway? Its leaves split by what the incident work is.

4.1 Detection and intake

The moment an incident becomes known, which is when many legal clocks start.

The glossary entry. In the Legal Handbook: Incident command: from the facts of an incident to the notices that are due.

4.2 Evidence preservation

Freezing logs, chain of custody, tamper-evident records.

In the Legal Handbook: What the law makes you able to show.

No mapped entry in the seed.

4.3 Clocks, notification and correction

Which legal event this is, in which jurisdiction, for which party; the deadline; the filing; the stop, rollback or recall.

The glossary entry. In the Legal Handbook: The incident clock.

4.4 Disclosure and advisories

Coordinated vulnerability disclosure, advisories, shared registries.

The glossary entry. In the Legal Handbook: Incident command: from the facts of an incident to the notices that are due.

Listed: Disclosure Check.

Every leaf, and how many entries it holds

LeafWhat it holdsMappedListedHandbook document
1.1Code and dependenciesSource, dependencies, licenses, secrets, infrastructure as code, model files.264What the law makes you constrain
1.2Agent configuration and declarationsWhat the agent says it is and can do: AGENTS.md, MCP manifests and tool descriptions, skills, A2A agent cards.00What the law makes you constrain
1.3Websites and published surfacesA live site read but not exercised: trackers, consent banners, policy pages, security headers, accessibility.00What the law makes you constrain
1.4Product descriptionsWhat the owner declares about the product: its activities, markets, data, users.20What the law makes you constrain
2.1Tester-runA person drives it, interactively or from a CLI, and reads the result.93What the law makes you constrain
2.2CI-integratedRuns unattended on every change and can fail a build.10What the law makes you constrain
3.1Execution sandboxesExecution sandbox: the box the agent runs in; it can touch only what the box allows. Never the regulatory kind.170How a gateway takes in legal constraint data
3.2Agent harnessesAgent harness: inside the agent's own loop; permission modes, approval prompts, hooks. Never the evaluation kind.1412How a gateway takes in legal constraint data
3.3GatewaysGateway: on the request path between the agent and its models, tools and other agents. A policy enforcement point.1719How a gateway takes in legal constraint data
3.4GuardrailsGuardrail: content and behavior classifiers a harness or gateway calls; they decide, something else enforces.21How a gateway takes in legal constraint data
3.5Policy enginesPolicy engine: the decision point. Evaluates a policy and returns allow, deny or escalate.50How a gateway takes in legal constraint data
3.6Identity and authorizationWho the agent is and what it is allowed to reach.82How a gateway takes in legal constraint data
3.7Admission and owner settingsDecided once, before the first call: what may be installed, deployed or used. The per-deployment gate.251How a gateway takes in legal constraint data
3.8Record-keepingRecords what ran. It does not constrain; the law places it on the system in operation (AI Act Art. 12).20What a tamper-proof log still cannot tell you
4.1Detection and intakeThe moment an incident becomes known, which is when many legal clocks start.50Incident command: from the facts of an incident to the notices that are due
4.2Evidence preservationFreezing logs, chain of custody, tamper-evident records.00What the law makes you able to show
4.3Clocks, notification and correctionWhich legal event this is, in which jurisdiction, for which party; the deadline; the filing; the stop, rollback or recall.20The incident clock
4.4Disclosure and advisoriesCoordinated vulnerability disclosure, advisories, shared registries.21Incident command: from the facts of an incident to the notices that are due

Reading the map

Across is the lifecycle: four stages, each split into leaves on a different question. Review splits by what is inspected, Testing by how it is run, Runtime by where the limit is enforced, Incidents by what the incident work is. A tool can sit in more than one leaf; its logo, or its filled dot, is its primary placement and its secondary placements show when you open it.

Down is whichever fact you choose: concern, home, license, maturity, or where a runtime tool's policy comes from. Position is a coded fact read from the product's own documentation, never a score. Changing the rows re-plots the same entries; nothing is re-classified.

Lane rules for facts that can hold more than one value. Concern: a tool is drawn in the narrowest concern it carries, legal before safety before security, because every tool here is at least a security tool and the rarer concerns would otherwise vanish. Policy source: the strongest source wins, an imported bundle before a decision-point callout before owner settings before vendor defaults. The lane heading says which rule applied.

Two tiers. A logo, or a filled dot where no logo has been collected, is a mapped entry: shipping, sourced, and taking part in a handoff or hosted by a foundation. A dashed count is the listed entries in that cell, searchable but not drawn, including every service and anything that only keeps an inventory.

Handoffs. Choose an artifact and the map shows who produces it (ringed dots) and who consumes it (hollow dots), with arcs from the producing leaves to the consuming ones. That is how a limit found in review or testing reaches the thing that runs.

What is empty is a finding. The striped cells have no mapped entry in the seed. Some are real gaps in the field (nothing yet consumes a legal-deadline artifact at runtime); some are gaps in the seed, which covered foundation projects, gateways and harnesses first and leaves the long tail to a later phase. The strip under the map says which.

What the map does not say. It does not rank, it does not grade in public, and it never says that a product satisfies an obligation. Where a stage answers to a law, the stage links the law; the product does not.

The map as a diagram

The 4 stages and 18 leaves of the safeguards map, with the artifacts that flow between them

The diagram as a file: SVG, PNG, SVG with the logos, PNG with the logos.

Where each stage answers to the law

The Safeguards Handbook

The Legal Handbook teaches the duties that reach an agent. This one teaches the tools that check and limit it, which is the map's own vocabulary. One document per thing a reader needs in order to read the map. This is the outline; none of the documents is written yet.

  1. Introduction. The four stages, and why a limit flows from one to the next.
  2. Review. What can be found without running anything, and what cannot: code and dependencies, agent configuration, published surfaces, product descriptions.
  3. Testing. By hand and in CI; what a test proves and what it does not; the four things a test can target.
  4. Runtime. Where a limit can be enforced, and who controls it: the sandbox, the harness, the gateway, the guardrail, the policy engine, identity, admission, the record.
  5. Harness or gateway. The distinction, with Harness² as the case for a protected limit.
  6. Handoffs. The formats that carry a definition between stages: findings, inventory, declarations, policy, vulnerability status, provenance, runtime records, legal deadlines, incident reports.
  7. Incidents. Detect, preserve, notify, correct; which clock is whose. Links the Legal Handbook's clocks and incident documents and teaches only what they leave out.
  8. Government sandboxes. What a regulatory sandbox should check (every law, not only the newest), and the four stages run by the authority. The argument lives here; the figure and the tracker live on the page.
  9. Reading the map. The text in the second tab, as a document.

What it leans on

Clocks and incidents are taught once, in the Legal Handbook, and linked from here; each document in this series will have an explainer on learn.lexlint.io.

The safeguards map is published by LexLint, and LexLint appears on it under the same rules as everyone else. Names, marks and logos belong to their owners; logos identify each product and are not part of the dataset.