AID-R-003.003: Progressive Capability & Privilege Re-enablement

Version 1.20261015 · Actionable sub-technique

Restore incident-affected tools, roles, permissions, delegated authority, and action edges one policy-defined tier at a time after locally verifying every prerequisite and reading back effective runtime authority.

Pillars: infra, app

Lifecycle: improvement

Scope boundary

Owns policy-staged re-enablement and readback of incident-affected tools, roles, permissions, delegated authority, and action edges after recovery prerequisites pass. It does not revoke the prior authority or replace per-action runtime authorization.

AID-E-001: AID-R-003.003 progressively grants new post-incident capability state; AID-E-001 revokes the compromised credential, principal, session, and grant populations. Re-enablement must follow verified eviction and cannot use a new privilege assignment as evidence that prior authority was removed.

AID-H-018: AID-R-003.003 restores which capabilities are available after an incident; AID-H-018 authorizes and constrains each runtime tool action and side effect. A restored capability tier does not itself authorize a specific invocation, parameter set, or external effect.

Implementation guidance

AID-R-003.003-G001

Re-enable tools and privileges progressively after post-restore verification.
Purpose and boundary

Use this progressive capability-restoration reference architecture to verify that each applicable tool, role, privilege, and authority edge was re-enabled only at the policy-approved tier after local prerequisite verification and that effective runtime authority equals the signed plan. It verifies every prerequisite locally before enabling a tier.

Define tiers and exact capability population

The authority signs the agent/user/workload and recovery release, baseline-denied capability manifest, tier policy, exact tool/action/role/permission edges per tier, parameter and target constraints, prerequisite receipt contracts, required approver roles, test manifests, effective-state readers, and exception policy. Tier names, waiting periods, risk thresholds, and approval counts are organizational policy inputs.

# File: recovery/contracts/progressive-capability-restore.yaml
schema_version: aidefend.r003.progressive-capability-restore.v1
required_bindings:
  - system_or_tenant
  - incident_id
  - recovery_release_id
  - principal_manifest_digest
  - transition_id
  - expected_tier_generation
  - ordered_control_plane_legs
  - baseline_denied_capability_digest
  - capability_tier_policy_digest
  - prerequisite_contract_registry_digest
  - positive_test_manifest_digest
  - negative_test_manifest_digest
  - exception_policy_digest
transition_receipt_required_fields:
  - principal_id
  - transition_id
  - from_tier
  - to_tier
  - prior_tier_generation
  - committed_tier_generation
  - expected_capability_edge_count
  - observed_capability_edge_count
  - prerequisite_receipt_digests
  - approver_subjects
  - effective_capability_digest
  - ordered_leg_receipts
  - unresolved_leg_ids
  - rollback_receipt_digests
  - denied_test_case_ids
  - result
Enforce at the authority boundary

Begin with all incident-affected optional capabilities denied at IAM, the tool gateway, agent registry, and data/action policy points. For a transition, independently verify every prerequisite signature, scope, target, freshness, and semantic contract; then apply one generation-bound leg at a time using expected-state comparison, compare-and-swap or fencing where available, idempotent transaction identity, and an ordered effective-state readback. Do not widen the next control plane until the current leg is independently verified. Timeout, provider outage, rejected write, stale generation, excessive or missing edge, missing readback, crash, or negative-test failure stops the sequence and returns every affected leg to the last independently verified lower tier or keeps it denied. Preserve the ordered partial history and retry only with the same transition identity and expected generation. If rollback itself cannot be verified, keep all not-yet-verified legs denied, mark the transition unresolved, and require operator remediation; never widen the next control plane. The owner records before/after edge sets, policy and release digests, approvals, transaction logs, test results, exceptions, and a detached-signed receipt in retention-locked evidence.

Independent readback

A verifier outside the capability owner trust domain enumerates effective IAM permissions, tool schemas, gateway policy, credentials, targets, and agent runtime configuration from authoritative read-only sources. It compares the complete edge set and generation at every control plane, requires an empty unresolved-leg population, and replays signed allowed and denied cases for every tier branch. Dependencies are signed tier and authority policies, complete principal/capability inventory, valid control-specific prerequisite receipts, approver directory, enforcement adapters, trusted time, and evidence store. Missing or non-pass prerequisites block transition but do not define this result.

Action: promote one signed tier transition at a time and fail closed on any mismatch; deployment configuration or approval alone is never effective-authority proof.

Open-source tools

Commercial / hosted tools

Threat mappings

MITRE ATLAS

MAESTRO

OWASP LLM Top 10 2026

OWASP ML Top 10 2023

OWASP Top 10 for Agentic Applications 2026

NIST Adversarial Machine Learning 2025

Cisco Integrated AI Security and Safety Framework

Google Secure AI Framework 2.0 - Risks

Databricks AI Security Framework 3.0

AID-R-003.003: Progressive Capability & Privilege Re-enablement | AIDEFEND

Loading interactive view…

AIDEFEND™

A Practical Knowledge Base for AI Security Defenses

Version

GitHub MCP Service