From scanning to shielding: defense-in-depth for AI agents
TL;DR: Scanners find problems. They do not prevent them. OpenA2A Shield combines five protection layers (credential blocking, configuration integrity, security scanning, runtime detection, and benchmark compliance) into a single orchestration layer. One command: opena2a shield init
The gap between scans
Most AI security tools are scanners. They analyze code, check configurations, flag vulnerabilities, and produce a report. Then they stop. The developer reads the report, fixes some findings, and goes back to work. The next scan might be tomorrow, next week, or never.
The question that matters is: what happens between scans? A new dependency gets added with a known CVE. A configuration file is modified to disable authentication. An API key is committed to version control. A runtime prompt injection exfiltrates data through a tool call. None of these events wait for the next scheduled scan.
Network security solved this problem decades ago with defense-in-depth: firewalls, IDS/IPS, endpoint detection, access control, and monitoring operating simultaneously. No single layer catches everything, but together they create overlapping coverage with no gaps.
AI agent security needs the same model. Scanning is one layer. It is not the full stack.
Five layers of protection
Defense-in-depth for AI agents requires coverage across five domains. Each layer addresses a distinct threat vector. Each operates independently so that a failure in one does not compromise the others.
Credential protection (Secretless)
Keep secrets out of AI context before they can be leaked. In Claude Code, Secretless installs a hook and deny rules that block reads of secret files. For Cursor, Copilot, Windsurf, and Cline it writes an instruction file that nothing enforces, and for Aider it writes ignore patterns. Credentials are stored in encrypted backends: local AES-256-GCM, OS keychain, 1Password, HashiCorp Vault, or GCP Secret Manager.
Configuration integrity (ConfigGuard)
Monitor configuration files for unauthorized changes. ConfigGuard computes SHA-256 hashes of tracked files and detects drift from the known-good baseline. When a config file changes outside of an expected workflow, an event is logged and an alert is raised.
Security scanning (opena2a review)
On-demand security posture assessment. Scans for hardcoded credentials, audits dependencies for known vulnerabilities, checks configuration hygiene, and produces a composite score. Tracks score changes over time so teams can measure progress.
Runtime detection (ARP)
Continuous monitoring of process, network, and filesystem activity at the OS level. AI-layer interceptors scan prompts, MCP tool calls, and A2A messages against 20 threat patterns covering prompt injection, tool misuse, data exfiltration, and identity spoofing. Real-time alerting on anomalous behavior.
Benchmark compliance (OASB)
Automated compliance scoring against the Open Agent Security Benchmark: 46 controls across 10 categories at 3 maturity levels. Gap analysis identifies which controls are missing and provides remediation guidance. Continuous compliance monitoring tracks whether your agent meets the baseline, not just once, but over time.
OpenA2A Shield: the orchestration layer
Shield is not another scanner. It is the orchestration layer that ties all five protection layers together. Shield delegates to specialized tools (Secretless for credentials, ConfigGuard for configuration integrity, ARP for runtime detection, OASB for compliance) and provides a single interface for visibility and control.
Without Shield, each tool runs independently. You check credentials with Secretless, run scans with opena2a review, monitor runtime with ARP, and assess compliance with OASB. That is four separate commands, four separate outputs, and four separate mental models to maintain.
With Shield, one command initializes all layers. One command shows the protection state across every layer. One event log records Shield's events, and each entry includes the SHA-256 hash of the entry before it.
Architecture
opena2a shieldOrchestration layer: initializes, monitors, and reports across all layersSecretlessCredential protection: file blocking, encrypted storage, runtime injectionConfigGuardConfiguration integrity: hash verification, drift detection, alertingopena2a reviewSecurity scanning: credentials, dependencies, hygiene, posture scoreARPRuntime detection: OS monitors, AI-layer interceptors, 20 threat patternsOASBBenchmark compliance: 46 controls, gap analysis, continuous monitoringThe workflow
Five commands take you from zero to full coverage.
npm install -g opena2a-cli$ opena2a shield init$ opena2a shield status$ opena2a review$ opena2a shield log --count 5Event log
Shield writes its events to one log file, ~/.opena2a/shield/events.jsonl. Each entry includes a SHA-256 hash that chains to the previous entry. The hashes use no key, so any program that can write the file, which includes programs running as the same user, can change or remove entries and recompute the hashes so that the chain still verifies.
The selfcheck command runs five checks: policy, shell-hook, event-chain, process and artifact-signatures.
Why not just scan more often?
Increasing scan frequency reduces the window of exposure but does not eliminate it. Even continuous scanning has fundamental limitations that defense-in-depth addresses.
| Limitation | Scanning Alone | Defense-in-Depth |
|---|---|---|
| Runtime attacks | Not visible until post-incident forensics | ARP detects in real time |
| Config drift | Detected at next scan (hours/days) | ConfigGuard detects immediately |
| Secret exposure | Found after the fact, cannot un-expose | Secretless prevents exposure entirely |
| Compliance gaps | Checked periodically | OASB monitors continuously |
Scanning remains valuable as Layer 3. It catches issues that other layers cannot: vulnerable dependencies, missing security configurations, hygiene problems. The point is that it works best alongside prevention and detection, not as a replacement for them.
What comes next
The architecture described above runs entirely locally. There are no network calls, no cloud dependencies, no accounts to create. This is intentional: the free, open-source tool is the foundation.
The enterprise extension, when it arrives, will be a configuration change rather than a rewrite. The event log already uses structured JSON schemas that can be forwarded to a centralized ingest. The identity model already supports optional organization and team fields. Policies are already loaded from YAML files that can be served from an API instead of disk.
What enterprise adds: centralized policy management, team-wide visibility across all developer workstations, aggregated compliance dashboards, and SSO integration. What it does not change: the local execution model, the zero-trust architecture, and the five-layer protection stack.
Changes to this post:
- , corrected what the post said about Shield's event log and the commands it prints. No measured value changed.
- Removed: the event log is tamper-evident and append-only, any modified, inserted or deleted entry fails the integrity check, and the log “prevents an attacker who gains access to the log from silently removing evidence of their activity.” Its hashes use no key, so anyone who can write the file can change entries and recompute them. A table row and a CI suggestion that rested on this were removed with it.
- The selfcheck description now names the five checks the command runs.
- Removed five example outputs that no CLI version printed: Steps 2 to 5 and a selfcheck result.
- Corrected two commands: the install command names the published package, opena2a-cli, and the event log command uses its --count option.
- , added a note that the npm package is opena2a-cli: install with npm install -g opena2a-cli.