aarm-policy-layer

Solid

Use when working on Gryph's AARM security layer or policy engine. Trigger this whenever the user changes code under aarm/ or cli/policy.go, or works on policy evaluation, the PDP, policy rules, CEL conditions, receipts and the receipt hash chain, receipt signing, the context accumulator, approvals, deferrals, identity capture, data classification, injection scoring, or the self-protection rules. Also trigger on phrases like "policy engine", "policy decision point", "AARM", "receipt chain", "gryph policy", "policy rule", or "context accumulator", even when the user does not name a file.

AI & Automation 161 stars 18 forks Updated 1 weeks ago Apache-2.0

Install

View on GitHub

Quality Score: 86/100

Stars 20%
74
Recency 20%
90
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# AARM / Policy Layer The full, current guide is `docs/aarm-dev.md`. It is the single source of truth for this task. Read it and follow it step by step. Do not change the AARM layer from memory. The layer spans about 15 packages under `aarm/`, plus the wiring in `cli/policy.go`. The request flow chains a normalize step, an identity gate, the context accumulator, the PDP, a decision branch, and a receipt write. A change in one step can break another. The doc maps the flow, the packages, and the extension points. ## How to use this skill 1. Read `docs/aarm-dev.md` in full. 2. Use the package map to find the right package for your change. 3. Add a Mediator dependency through a `MediatorOption` in `aarm/check.go`, then wire it in `loadPolicyMediator` in `cli/policy.go`. 4. Run `make test` and `make lint` before you finish. Run `make generate-schema` after any change to the policy schema or a payload type. ## Invariants Three invariants break silently if you miss them. The doc explains all three. 1. The receipt and context hashes are consensus formats. A change to field order or canonicalization breaks every existing chain. Update the verifier and the property tests in the same change. 2. The `aarm` package stays decoupled from `storage` and `cli`. Carry CLI-shaped side effects through the hooks (`DeferralHook`, `ApprovalAuditHook`, `IdentityAuditHook`). Do not add a `storage` or `cli` import to `aarm`. 3. Policy resolution is additive and same-user safe. `disabled:` is sco...

Details

Author
safedep
Repository
safedep/gryph
Created
7 months ago
Last Updated
1 weeks ago
Language
Go
License
Apache-2.0

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

ackit-policy-authoring

Author layered ackit policy files with deterministic merge, scoping and lockable rules.

14 Updated 3 days ago
Cynrath
API & Backend Solid

gryph-policy-authoring

Use when a human wants help to author or change a Gryph security policy that governs what an AI coding agent may do, often with an agent's help. Trigger whenever the user wants Gryph to block, allow, warn on, or require approval for an agent action, wants to write or change a policy rule, asks how to match a tool, command, file path, or URL, works with CEL conditions or context counters, wants to split policy into many files, or wants to dry-run a rule. Also trigger on phrases like "write a gryph policy", "add a policy rule", "make gryph block X", "help me write a policy", or "policy for my agent", even when the user does not name a file. This skill drafts a policy in a workspace directory and hands the user an install command. It never installs the policy and never writes into Gryph's config directory. It is not for changing the policy engine code (use aarm-policy-layer for engine work under aarm/ or cli/policy.go).

161 Updated 1 weeks ago
safedep
AI & Automation Listed

usage-policy-writer

Generate a human-facing AI usage policy with approved tools, data classification, risk model explanations, and exception processes — saved to $HOME/.ai-first-kit/. Produces a policy document for HUMANS (not agents) that explains what AI tools are approved, what data can be used with AI, and the reasoning behind each decision. Use when the user says 'AI usage policy', 'AI handbook', 'what tools are approved', 'data classification for AI', 'AI rules for the team', 'usage guidelines', 'AI policy', 'human AI rules', 'acceptable use policy', or 'what can we use AI for'. Also use when the user describes people unsure what they're allowed to do with AI, different teams having different answers about approved tools, no clear policy about client data and AI, or needing to explain the 'why' behind AI rules — even if they don't use the word 'policy'. This skill MUST be consulted because it produces a structured human-facing policy with risk model reasoning and exception processes; a conversational answer cannot create t

6 Updated today
synaptiai