OAP Policy Pack Integration: SHIELD Threat Intelligence Import

[uchibeke]

Overview

OAP v1.0 provides W3C Verifiable Credential-based authorization infrastructure for AI agents, including:

• Cryptographically signed agent passports with DID-based identity
• Policy packs defining capabilities, limits, and enforcement rules
• Deterministic evaluation with sub-100ms decisions
• Compliance-grade audit trail (tamper-evident, signed)

This proposal adds support for importing SHIELD threat intelligence into OAP policy packs, enabling users to leverage community-curated threat definitions alongside ClawMoat detection findings, CVE databases, and custom rules.

Architecture

┌─────────────────────────────────────────────────────────┐
│ OAP v1.0 Authorization Standard                         │
│ • W3C VC/DID-based identity                            │
│ • Signed policy packs                                  │
│ • Deterministic enforcement                            │
│ • Cryptographic audit trail                            │
└─────────────────────────────────────────────────────────┘
            ↑ (imports from multiple sources)
┌─────────────────────────────────────────────────────────┐
│ Threat Intelligence Sources                             │
│ • SHIELD.md (community threat definitions)             │
│ • ClawMoat (runtime detection findings)                │
│ • CVE databases (known vulnerabilities)                │
│ • Custom rules (organization-specific)                 │
└─────────────────────────────────────────────────────────┘

Proposed Integration: SHIELD → OAP

Field Mapping

SHIELD Field	OAP Policy Pack Field	Notes
threat_id	policy.rules[].id	Unique identifier
category	policy.rules[].scope	Maps to OAP capability scopes
action (block/require_approval/log)	policy.rules[].enforcement	Decision type
severity + confidence	policy.rules[].priority	Combined into priority score
matched_on	policy.rules[].conditions	Pattern matching rules

Example

SHIELD.md entry:

---
threat_id: T001
category: tool
action: block
severity: critical
confidence: 0.95
---
Block commands containing `rm -rf`

Converted to OAP policy pack rule:

{
  "id": "shield_T001",
  "scope": "system.command.execute",
  "enforcement": "deny",
  "priority": 10,
  "conditions": {
    "patterns": {
      "blocked": ["rm -rf"]
    }
  },
  "source": "shield:T001",
  "reason": "Block commands containing rm -rf"
}

CLI Tool: shield-to-oap

Usage:

# Import SHIELD threats into existing policy pack
shield-to-oap import shield.md -o policy-pack.json

# Merge with existing policy pack
shield-to-oap merge shield.md existing-policy.json -o merged-policy.json

# Validate SHIELD → OAP mapping
shield-to-oap validate shield.md

Output: OAP-compliant policy pack JSON (unsigned, user signs via passport)

Multi-Source Threat Intelligence

OAP policy packs can aggregate rules from multiple sources:

{
  "policy_pack_id": "combined-threats-v1",
  "rules": [
    {"id": "shield_T001", "source": "shield:T001", ...},
    {"id": "clawmoat_C042", "source": "clawmoat:prompt-injection", ...},
    {"id": "cve_2024_1234", "source": "cve:CVE-2024-1234", ...},
    {"id": "custom_R001", "source": "custom", ...}
  ]
}

Benefits:

• ✅ SHIELD for community-curated threats (easy markdown format)
• ✅ ClawMoat for runtime detection findings (ML-based)
• ✅ CVEs for known vulnerabilities (industry standard)
• ✅ Custom rules for organization-specific policies
• ✅ All enforced through single OAP authorization layer

Implementation Plan

Week 1: Schema Definition

• Finalize SHIELD → OAP field mapping
• Define source attribution format (source field)
• Document multi-source aggregation rules

Week 2: CLI Tool

• Build shield-to-oap importer
• Add validation and merge capabilities
• Publish as utility in aport-agent-guardrails repo

Week 3: Documentation & Testing

• Write integration guide
• Test with OpenClaw plugin
• Coordinate with ClawMoat for detection → OAP flow

Feedback Requested

1. Is the field mapping accurate for SHIELD's intended use cases?
2. Should we support bidirectional export (OAP → SHIELD)?
3. How should conflicting rules from different sources be resolved?
4. What other threat intelligence sources should OAP support?

---

Related:

• OAP v1.0 Spec
• OpenClaw Issue #12385
• SHIELD.md Spec

---

[uchibeke]

Update on this

I pulled together a concrete proposal at https://github.com/aporthq/aport-spec/tree/main/integrations/shield and would love feedback before we wire up the importer.

Summary

• OAP v1.0 already defines the enforcement layer (passports, policy packs, evaluation rules). SHIELD.md provides a community-driven threat feed (scopes, severity, confidence, action). We propose embedding SHIELD threats directly inside existing policy packs (e.g., policies/system.command.execute.v1/policy.json) so the same feed can be enforced deterministically via APort guardrails.
• Concretely, we introduce limits.{capability}.shield.threats[], where each entry mirrors SHIELD fields (id, action, severity, confidence, conditions, lifecycle metadata). Evaluation rules gain a type: "shield" entry that tells the guardrail to evaluate those threat conditions and apply the three-state outcome before executing a tool.
• Confidence semantics follow SHIELD’s definition (≥0.85 enforceable; otherwise downgrade to require_approval unless severity is critical). The guardrail emits the exact decision text SHIELD v1 requires (“Blocked. Threat matched: …”).

Questions for the community

1. Should SHIELD threats live under limits.{capability}.shield (per proposal) or as a new top-level threat_feeds object shared across capabilities?
2. Do we need bidirectional export (OAP → SHIELD) for round-trip editing, or is one-way import sufficient?
3. Conflict resolution: if multiple feeds define overlapping conditions, should we prefer highest severity, most recent update, or require explicit priority fields?
4. How should we encode recommendation_agent directives that reference free-form text rather than explicit strings (e.g., heuristics like “outbound request to any unknown domain”)?

Next steps

• Gather feedback on the structure + questions above.
• Ship a shield-to-oap CLI in @aporthq/agent-guardrails so developers can ingest SHIELD files directly into their policy packs.
• Publish an example policy + guardrail log showing the Cisco exfiltration scenario blocked via SHIELD → OAP → APort.