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)
Block secrets from entering AI context before they can be leaked. Secretless installs file-blocking rules for every major AI coding tool (Claude Code, Cursor, Copilot, Windsurf, Cline, Aider) and stores credentials in encrypted backends -- local AES-256-GCM, OS keychain, or 1Password.
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 captures activity from all sources with a tamper-evident SHA-256 hash chain that detects if any log entries have been modified or deleted.
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$ opena2a shield init
OpenA2A Shield v0.3.5
Initializing protection layers...
[1/5] Secretless Credential protection configured
[2/5] ConfigGuard Configuration integrity baseline set
[3/5] Review Security scanner ready
[4/5] ARP Runtime monitors configured
[5/5] OASB Benchmark controls loaded
Shield initialized. Run 'opena2a shield status' to verify.$ opena2a shield status
Shield Status
Layer 1 Secretless active 3 AI tools protected, 0 exposed secrets
Layer 2 ConfigGuard active 12 files tracked, 0 drift detected
Layer 3 Review ready Last scan: 2 min ago, score: 71/100
Layer 4 ARP active 3 monitors running, 0 violations
Layer 5 OASB ready L1 compliance: 68%
Event log: 47 entries, integrity verified$ opena2a review
Security Review
Credentials 0 exposed (Secretless active)
Dependencies 2 advisories (1 moderate, 1 low)
Hygiene .gitignore present, lock file present
Score 71/100 -> 85/100 by fixing 2 dependency advisories$ opena2a shield log --last 5
Event Log (last 5 entries)
03-04 14:23 shield.init Shield initialized, 5 layers active
03-04 14:23 configguard.baseline 12 files baselined
03-04 14:25 review.scan Score: 71/100
03-04 14:31 configguard.drift package.json modified (expected)
03-04 14:31 review.scan Score: 71/100 (no change)
Integrity: all hashes verifiedTamper-Evident Event Log
Every action across all five layers is recorded in a single append-only event log. Each entry includes a SHA-256 hash that chains to the previous entry. If any entry is modified, inserted, or deleted, the hash chain breaks and the integrity check fails.
This matters for two reasons. First, it provides a reliable audit trail. When something goes wrong, you can trace exactly what happened and when. Second, it prevents an attacker who gains access to the log from silently removing evidence of their activity.
$ opena2a shield selfcheck
Shield Integrity Check
Event log 47 entries, hash chain valid
Config hashes 12/12 verified, 0 drift
Identity Ed25519 key present, signature valid
Modules 5/5 loaded, no tampering detected
Result: PASSThe selfcheck command verifies the integrity of the event log, configuration hashes, the local Ed25519 identity key, and all loaded Shield modules. It is designed to be run in CI pipelines and pre-deployment gates.
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 |
| Log tampering | No integrity guarantee on scan results | Hash-chained event log detects modification |
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.