-
Notifications
You must be signed in to change notification settings - Fork 0
Textbook 14 Reference Appendices
- CLI
- API
- Diagrams
- Edition Boundaries
- Open Core Implementation Plan
- Private Enterprise Repo Plan
- Policy Engine Hardening
- Approval Workflows
- Evidence Hub And Attestation
- Agent Registry And MCP Trust
- AI Agent Enforcement And Anti-Bypass Model
- AISPM Dashboard Roadmap
- AI Security Posture Dashboard Contract
- AISPM CSO Report Center
- AISPM Enterprise Live Ingestion
- Azure Community SaaS Deployment
- Azure Trial And Enterprise Deployment
| Family | Representative commands |
|---|---|
| Core |
cavra version, cavra evaluate
|
| Agent |
cavra agent start, cavra agent exec, cavra agent attest
|
| Policy |
cavra policy list, validate, test, explain, sign, verify
|
| Approval |
create, list, approve, deny, expire, break-glass, route, deliver
|
| Evidence |
bundle, verify, verify-attestation, index, search, export-siem
|
| Registry |
agent-register, agent-list, mcp-register, mcp-list, mcp-check
|
| Ops |
stores, backup, restore, retention-plan
|
| Runtime | Go rollback drill and runtime governance command families |
| Release | package verification, rollout, promotion, rollback, endpoint, remediation, SLA, connector delivery |
| Demo |
cavra init claude-code, cavra demo before-the-agent-acts
|
| Term | Meaning |
|---|---|
| Agent | An AI system or coding assistant that proposes or executes engineering actions. |
| AISPM | AI Security Posture Management, the posture and reporting layer built from CAVRA evidence. |
| Approval | A human or provider-backed decision that permits or denies a routed action. |
| Attestation | A signed or verifiable statement tying an action, PR, or bundle to evidence. |
| Break glass | Emergency authorization with explicit reason, actor, and audit trail. |
| Connector | Integration that delivers or retrieves evidence, reports, tickets, alerts, or workflow records. |
| Evidence bundle | A package of decision and operating proof generated by CAVRA. |
| MCP trust | Governance model for MCP servers, capabilities, tools, and approval states. |
| Policy pack | A set of rules that decide what actions are allowed, denied, or routed. |
| Runtime authority | The CAVRA decision point that evaluates an action before it proceeds. |
| Tenant | An isolated Enterprise customer or organization boundary. |
This appendix keeps the quick FAQ close to the reference material. For the full field playbook, use Troubleshooting And FAQ.
Run:
cavra policy explain <action> <target>Check whether the policy pack, action type, resource path, command string, Git target, or MCP trust state matches what you expected. If the action is legitimate, route it through approval rather than weakening the policy silently.
The command pattern is probably too broad. Replace broad globs with narrower allow or approval rules, then run:
cavra policy validate .cavra/policy.yaml
cavra policy test --policy-pack cavra-ai-agent-baselineThe policy pack may not contain a matching command rule, or the action type may have been normalized incorrectly. Add an explicit rule, then run cavra policy explain against the risky command.
Run:
cavra approval list --state pendingConfirm the route owner, expiry, provider delivery state, and escalation path. If the request is stale, expire it and ask the requester to resubmit with better context.
Check the bundle path, manifest, trust root, key ID, and signature material. Regenerate the trust root only when you understand why verification failed; do not paper over a broken evidence chain.
Confirm you are serving apps/sandbox-ui from the repository root, then hard-refresh the browser. The public sandbox is static, so it demonstrates product state and sample flows rather than connecting to private Enterprise tenants.
Open the readiness packet and resolve blockers one by one. Common blockers include missing real connector validation, unverified report delivery, tenant isolation gaps, stale evidence, and synthetic-only runtime workflows.
Public contracts include dashboard, report catalog, setup, delivery audit, operations dashboard, retention lifecycle, search and retrieval, export package manifest, schedule policy, recipient policy, approval decision, exception lifecycle, evidence room, incident packet, closure, KPI metrics, alert escalation, drilldown, remediation plan, remediation closure, executive digest, digest distribution, trial validation, operator dashboard, evaluator handoff, and publication readiness schemas.
See AI Security Posture Dashboard Contract for schema links and public-safe examples.
Implementation and validation history is archived in Development And Testing Artifacts. Use it when you need release evidence, trial-sync records, closeout notes, validation packets, or historical implementation context.
- Which appendix helps you find canonical product pages?
- Which command family verifies evidence bundles and attestations?
- Where should historical development and testing records live?
Read Policy Language Reference for complete policy syntax, then Troubleshooting And FAQ, and finish with Conclusion: The Runtime Authority Revolution.
Before the agent acts, CAVRA asks: who is acting, what will change, what policy applies, and what evidence will prove it?
| Start | Build | Operate | Assure |
|---|---|---|---|
| Quick Start | CLI | Enterprise Guide | AISPM |
| Reader Paths | Policy Syntax | Deployments | Evidence |
| Community | GUI | Troubleshooting | Conclusion |
- Foreword And Reader Paths
- Why CAVRA Exists
- Runtime Authority Model
- Architecture
- Editions
- Install And Deploy
- Community Guide
- Enterprise Guide
- CLI Reference
- GUI And Sandbox
- AISPM Guide
- Policy And Evidence
- Operations And Integrations
- Labs And Use Cases
- Appendices And FAQ
- Policy Language Reference
- Troubleshooting Playbook
- Conclusion