Rule overview
Foo Guard deterministic production rules AG-001 through AG-031.
Page text and source link for your AI assistant. Nothing is sent automatically.
Foo Guard uses a deterministic production rules engine. Rule semantics, severity, and scoring do not change based on AI output.
Browse individual rule pages under Rules & Findings or open rule documentation directly from a finding.
Rule packs
A scan can keep the registered Foo Guard catalog or start from a related-check pack. The packs are Foo Guard catalog, OWASP Top 10 for LLM Applications version 2025 (released 2024-11-18), OWASP Top 10 for Agentic Applications 2026 (released 2025-12-09), and AICPA Trust Services Criteria (2017) Security criteria CC6.1, CC6.2, CC6.3, and CC7.2.
A framework entry is recorded as assessed only when every related check for that entry stays selected. Unselected checks are not a pass. Secret checks still run. Fail-on, minimum grade, and policy exceptions stay separate from the pack.
Each saved scan stores the pack id, pack version, catalog version, and selected rule ids. Scores from different selections are not equivalent. These packs are configuration checks that can help work toward a framework. They are not an OWASP certification, a SOC 2 examination, or a complete compliance assessment.
Repository CI and the v1 analyze API keep the registered catalog. They do not accept a rule pack.
Tool control declarations
AG-024 reviews an explicitly destructive tool with authentication explicitly disabled. AG-025 reviews a conflict between enabled global approval and disabled approval for an explicitly destructive tool. Both are medium-severity configuration concerns; neither demonstrates runtime exposure or a bypass. Missing fields remain unknown. These checks apply to the default catalog and may be selected individually; existing framework packs retain their current mappings.
The catalog version changes when checks are added. New scans may therefore differ from older scans; retained scan results are not rewritten. Compare scans with matching rule coverage before attributing a score change to a configuration change.
Gateway tool-definition changes are reviewed separately from static configuration scores. Discovery compares the full returned definition with its reviewed version, including descriptions, schemas, and annotations. A changed tool requires explicit selection during a fresh review; refreshing inventory never grants access. Server-provided metadata is a declaration, not proof of behavior.
Additional tool controls
Catalog 2026-10-11.4 adds five checks to the default catalog. Existing framework packs retain their mappings. Saved assessments keep their original results; a new scan can have a different score under the new catalog.
- AG-026: explicitly mutating tools with agent logging explicitly disabled (medium).
- AG-027: non-loopback HTTP tool URLs, or HTTPS certificate verification explicitly disabled (medium).
- AG-028: supported
npxregistry package specifications without an exact version (low). Local dependency and lockfile resolution are not inspected. - AG-029: supplied credential references outside an explicitly declared required set (medium).
- AG-030: an explicit read-only declaration conflicting with explicit mutation on the same tool (medium).
- AG-031: a raw provider key on a server or provider that the workspace already routes through the Gateway (high). It runs only when a scan knows the workspace's Gateway routes, and stays silent otherwise, including in anonymous scans. It is not yet supplied to workspace scans.
These are configuration checks, not runtime tests. Missing, malformed, unsupported, or redacted fields do not establish a violation. A result with no finding does not prove the property was assessed or enforced. Names and prose descriptions alone do not trigger these additions.
Supported declarations and examples
{
"auditability": { "loggingEnabled": false },
"tools": [{
"name": "example-tool",
"writesData": true,
"readOnly": true,
"url": "http://tools.example.com/mcp",
"command": "npx",
"args": ["example-tool@latest"],
"credentialRefs": ["reports", "deployment"],
"requiredCredentialRefs": ["reports"]
}]
}This synthetic example triggers all five checks. Correct it by enabling logging, accurately declaring mutation, using a verified HTTPS connection, pinning a reviewed version such as example-tool@1.2.3, and removing the unneeded deployment credential binding. Changing declarations alone does not configure real enforcement.
AG-026 and AG-030 recognize explicit writesData, modifiesResources, and destructive flags; the first two also accept snake_case. Read-only declarations use readOnly, read_only, or annotations.readOnlyHint. MCP destructiveHint is not treated as an independent mutation declaration when a read-only hint is set.
AG-027 reads url (preferred) or endpoint. Certificate settings are verifyTls, verify_tls, rejectUnauthorized, tls.verify, or tls.rejectUnauthorized. HTTP loopback URLs (localhost, its subdomains, IPv4 127/8 and IPv6 ::1) are excluded; private network addresses are not excluded. It performs no requests or DNS lookups. HTTPS certificate checks require a declared HTTPS URL.
AG-028 supports command: "npx" (including an executable path or npx.cmd) with a string args array, direct registry package arguments, and --package / -p. Unknown options, shell wrappers, other launchers, URLs, git references and local paths are not assessed. An exact package version does not verify package integrity or transitive dependencies.
AG-029 uses Foo Guard declarations credentialRefs and requiredCredentialRefs, both arrays of nonempty, case-sensitive reference names. An empty required list is meaningful; an absent or malformed list is unknown. These are reference names, never secret values. They do not automatically bind or remove credentials in a client.
Connection and launch checks also read top-level mcpServers objects. A server declaration is not a discovered runtime tool inventory, and its name does not imply capabilities:
{
"mcpServers": {
"example": {
"command": "npx",
"args": ["example-tool@1.2.3"]
}
}
}Launcher interpretation follows the npm npx documentation. Treat MCP annotations as hints, as explained in the MCP annotation guidance.