Your AI Agents Have a Security Posture. Here's How to Measure It.

Most teams building AI agents have no idea what their security posture looks like. They know they should be doing something — hardening prompts, validating tool outputs, locking down memory access — but "something" remains frustratingly vague. There is no checklist that feels complete. There is no scanner that tells you what you missed.

Until now.

Today we are releasing g0 — an open-source CLI that scans your AI agent codebase against 1,214 security rules across 12 domains. Run it against your repo and you will have, for the first time, a concrete, measurable security posture for your agent. Not a gut feeling. An actual number, with findings you can triage, assign, and fix.

#What is g0

g0 is to AI agent security what ESLint is to JavaScript code quality. It is a static analysis tool that reads your agent code — your prompts, your tool definitions, your MCP configurations, your memory implementations, your orchestration logic — and tells you exactly where the security gaps are.

npx @guard0/g0 scan ./my-agent

That single command produces a structured report mapping every finding to a severity level, a remediation recommendation, and the relevant OWASP Agentic Top 10 control (ASI01 through ASI10).

g0 is fully open-source. It runs locally. Your code never leaves your machine. You can integrate it into your CI pipeline in under five minutes.

#What g0 Scans

g0 covers the 12 domains that define modern AI agent attack surface. Most security tools were not built with agents in mind. g0 was built for nothing else.

#1. Prompt Injection Defenses

Prompt injection remains the most exploited class of AI agent vulnerability. g0 checks whether your system prompts contain injection-resistant patterns, whether user-supplied content is sanitized before reaching the model, and whether your agent has any defense against indirect injection via tool outputs or retrieved documents.

#2. Tool and MCP Security

Every tool your agent can call is a potential privilege escalation vector. g0 scans your tool definitions for overly broad permissions, missing input validation, and unsafe parameter handling. It includes dedicated rules for MCP server configurations, covering transport security, capability scoping, and authentication requirements.

#3. Authentication and Authorization

Agents that can act on behalf of users need to handle identity correctly. g0 checks for hardcoded credentials, missing authorization gates on sensitive tool calls, and improper session handling in multi-turn conversations.

#4. Data Handling and Privacy

Agents that process user data or call external APIs are subject to data handling obligations. g0 flags patterns that suggest PII is being logged, passed to third-party tools without sanitization, or stored in memory without appropriate controls.

#5. Output Validation

Agent outputs that feed downstream systems — databases, APIs, other agents — need validation before they are trusted. g0 checks whether your agent's outputs are validated before being acted upon, and whether structured output schemas are enforced.

#6. Memory Security

Long-term and short-term memory implementations introduce a new class of vulnerabilities. g0 scans your memory read and write patterns for missing access controls, potential memory poisoning vectors, and unbounded retrieval that could expose sensitive context from unrelated sessions.

#7. Multi-Agent Communication

Orchestrators talking to subagents, subagents calling other subagents — multi-agent systems have a trust boundary problem that most implementations ignore. g0 checks whether your agent-to-agent communication is authenticated, whether messages are validated before being acted upon, and whether agent identities are verified.

#8. Logging and Monitoring

You cannot detect an attack you are not logging. g0 checks for the presence and completeness of agent audit trails: are tool calls logged? Are prompt inputs and outputs captured? Is there anomaly detection on agent behavior?

#9. Error Handling

Poor error handling in agents frequently leaks sensitive information — system prompt contents, internal tool names, stack traces with API keys. g0 scans your error handling patterns for information disclosure risks.

#10. Dependency Security

g0 checks your agent's dependency tree for known vulnerabilities in the SDKs and libraries you are using, including agent frameworks, vector store clients, and model provider SDKs.

#11. Configuration Security

Environment variables, API keys, model parameters — g0 scans your configuration files and surfaces anything that looks like a hardcoded secret, an insecure default, or a misconfigured model parameter (such as a temperature setting that makes outputs unpredictable in security-sensitive contexts).

#12. Compliance Readiness

g0 checks your agent implementation against a set of controls required by emerging AI governance frameworks, including EU AI Act Article 9 risk management requirements and NIST AI RMF controls relevant to agentic systems.

#1,214 Rules, Organized for Real Triage

1,214 rules is a large number. The g0 rule taxonomy is designed so that you are never looking at an undifferentiated list of findings.

Every rule has:

• A severity level: critical, high, medium, low, or informational
• A domain: one of the 12 listed above
• An OWASP Agentic Top 10 mapping: where applicable, the finding maps to ASI01 through ASI10
• A remediation description: concrete steps to fix the issue, not just a description of the problem
• A rule ID: stable identifiers like G0-PINJ-001 for prompt injection rules, G0-TOOL-042 for tool security rules, enabling you to suppress specific findings with a comment or a config entry

The OWASP Agentic Top 10 is the closest thing the industry has to a shared vocabulary for agent security risk. The ten controls are:

g0 maps its findings to these controls so your security team, your compliance team, and your engineering team are all looking at the same framework.

#Tutorial: Running Your First Scan

Let's walk through a realistic scan. Assume you have an agent project with the following structure:

my-agent/
  agents/
    research_agent.py
    email_agent.py
  tools/
    web_search.py
    email_sender.py
    database_query.py
  config/
    agent_config.yaml
  prompts/
    system_prompt.txt
  requirements.txt

Run the scan:

npx @guard0/g0 scan ./my-agent

You will see output like this:

g0 v0.9.0 — AI Agent Security Scanner
Scanning: ./my-agent
Rules loaded: 1,214 across 12 domains
 
Scanning agents/research_agent.py...
Scanning agents/email_agent.py...
Scanning tools/web_search.py...
Scanning tools/email_sender.py...
Scanning tools/database_query.py...
Scanning config/agent_config.yaml...
Scanning prompts/system_prompt.txt...
Scanning requirements.txt...
 
--- FINDINGS ---
 
CRITICAL  G0-PINJ-001  agents/research_agent.py:47
  User input passed directly to system prompt without sanitization
  Domain: Prompt Injection Defenses | OWASP: ASI01
  The value of `user_query` is interpolated into the system prompt string
  at line 47 without any sanitization. An attacker can use this to override
  agent instructions.
  Fix: Use a structured message format that separates system instructions
  from user input. Never concatenate user input into the system prompt.
 
CRITICAL  G0-AUTH-007  tools/email_sender.py:12
  Hardcoded API credential detected
  Domain: Authentication & Authorization | OWASP: ASI02
  A string matching the pattern of a SendGrid API key was found hardcoded
  at line 12. Rotate this key immediately and move it to an environment variable.
  Fix: Use environment variables or a secrets manager. Reference via
  `os.environ.get("SENDGRID_API_KEY")`.
 
HIGH      G0-TOOL-019  tools/database_query.py:88
  Tool accepts arbitrary SQL without parameterization
  Domain: Tool/MCP Security | OWASP: ASI06
  The `execute_query` function at line 88 accepts a raw SQL string from the
  agent and executes it without parameterization. An agent under prompt
  injection could be instructed to run destructive queries.
  Fix: Use parameterized queries. Consider restricting the tool to a
  predefined set of allowed query patterns.
 
HIGH      G0-MEM-003   agents/research_agent.py:134
  Memory retrieval has no session isolation
  Domain: Memory Security | OWASP: ASI08
  The vector store retrieval at line 134 queries across all sessions. A
  crafted query could retrieve memory fragments from other users' sessions.
  Fix: Filter memory retrieval by session ID or user ID. Namespace your
  vector store embeddings by user.
 
MEDIUM    G0-LOG-002   agents/email_agent.py:201
  Tool call inputs and outputs are not logged
  Domain: Logging & Monitoring
  No logging statements were detected around the tool call at line 201.
  Without audit logging, you cannot reconstruct agent behavior after
  an incident.
  Fix: Log tool name, input parameters (sanitized), and output summary
  for every tool call.
 
MEDIUM    G0-CFG-011   config/agent_config.yaml:8
  Model temperature set to 1.0 for security-sensitive agent
  Domain: Configuration Security
  A temperature of 1.0 increases output unpredictability, which is
  problematic for agents making authorization decisions.
  Fix: For agents performing security-sensitive operations, use
  temperature <= 0.2.
 
LOW       G0-DEP-044   requirements.txt:14
  langchain==0.0.267 contains known vulnerabilities (CVE-2023-46229)
  Domain: Dependency Security | OWASP: ASI03
  Fix: Upgrade to langchain>=0.1.0
 
--- SUMMARY ---
 
  Critical:      2
  High:          2
  Medium:        2
  Low:           1
  Informational: 0
 
  Total findings: 7
  Files scanned: 8
  Rules evaluated: 1,214
 
  Security score: 61 / 100
  OWASP coverage gaps: ASI01, ASI02, ASI03, ASI06, ASI08
 
Run `npx @guard0/g0 report --format html` for the full interactive report.

The scan also produces a domain-level radar view of your agent's security posture, making it easy to see which areas are strong and which need attention.

The two critical findings are where to start. The hardcoded API key (G0-AUTH-007) needs to be rotated immediately — not fixed, rotated, because it has already been in your codebase and possibly in your git history. The prompt injection finding (G0-PINJ-001) is the most common way agents get compromised.

The high findings come next. The unsanitized SQL tool (G0-TOOL-019) is a direct path from prompt injection to database destruction. The memory isolation issue (G0-MEM-003) is a privacy and compliance risk.

Mediums and lows are real but not on fire. Schedule them.

#CI/CD Integration

A security scanner only works if it runs on every change. g0 is designed to be a CI gate, not just a developer tool.

GitHub Actions:

name: Agent Security Gate
 
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
 
jobs:
  g0-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Run g0 Security Scan
        run: npx @guard0/g0 scan ./agents --format sarif --fail-on high
 
      - name: Upload SARIF to GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: g0-results.sarif

The --fail-on high flag means the job fails if any high or critical findings are detected, blocking the merge. The SARIF output integrates directly with GitHub's Security tab, so findings appear as code scanning alerts on pull requests.

You can also configure a .g0rc.yaml in your project root to customize behavior:

# .g0rc.yaml
fail_on: high
exclude_rules:
  - G0-INF-001  # suppress informational noise
exclude_paths:
  - tests/
  - fixtures/
domains:
  - prompt_injection
  - tool_security
  - authentication
  - data_handling
  - output_validation
  - memory_security
  - multi_agent
  - logging
  - error_handling
  - dependencies
  - configuration
  - compliance

#OpenClaw Scanning

g0 ships with a dedicated rule set for OpenClaw, the widely-used open-source MCP server framework. The OpenClaw rules cover the CVEs discovered during our security research — vulnerabilities present in default OpenClaw configurations that allow prompt injection via malicious MCP tool responses, session token leakage through improper transport handling, and privilege escalation via unchecked tool capability declarations.

If g0 detects OpenClaw in your dependency tree or your MCP configuration files, it automatically activates the OpenClaw rule set and surfaces any affected patterns in your codebase.

For full details on what we found and why it matters, see The OpenClaw Security Crisis.

#From CLI to Fleet

g0 is built for the individual developer or a single team managing a handful of agents. Run it locally. Run it in CI. Get a score. Fix the findings.

But organizations running agent infrastructure at scale face a different set of problems. When you have dozens of agents across multiple teams, products, and cloud environments, you need more than a CLI.

You need to know the aggregate security posture across your entire agent fleet, not just the last scan of a single repo. You need policy enforcement that is consistent across teams regardless of which framework they are using or which cloud they are deploying to. You need continuous monitoring that catches runtime drift — agents whose behavior changes after deployment, or new tool connections that were not present when the last scan ran. And you need compliance reports that can be handed to auditors without manual compilation.

That is what the Guard0 platform provides. It extends g0 with:

• Centralized policy management: define security policies once, enforce them across every agent in your organization
• Continuous monitoring: runtime visibility into agent behavior, tool usage patterns, and anomalies
• Compliance reporting: automated evidence collection for SOC 2, ISO 42001, and EU AI Act requirements
• Fleet-wide scoring: a live security posture dashboard across all your agents, updated as code changes

If you are building at that scale, the AI-SPM guide is a good place to understand the discipline that Guard0 is operationalizing.

#Get Started

Star g0 on GitHub and run your first scan:

npx @guard0/g0 scan ./your-agent

Source code, documentation, and the full rule set are at github.com/anthropics/guard0.

Running agents at fleet scale? The Guard0 platform extends g0 with centralized policy management, continuous monitoring, and compliance reporting. Book a demo to see how it works for your organization.