@samirosamsam/aim 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/plugins/marketplace.json +20 -0
- package/.codex-plugin/plugin.json +24 -0
- package/LICENSE +21 -0
- package/README.md +147 -0
- package/bin/aim.js +392 -0
- package/hooks/hooks.json +17 -0
- package/package.json +40 -0
- package/skills/aim/SKILL.md +88 -0
- package/skills/aim/agents/openai.yaml +4 -0
- package/src/engine.js +685 -0
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: aim
|
|
3
|
+
description: Install and manage deterministic AIM guardrails for Codex tool calls. Use when the user asks Codex to block, prevent, deny, or enforce precise behavior around Bash, file edits, or MCP tools.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# AIM
|
|
7
|
+
|
|
8
|
+
Use the public `aim` CLI as the source of truth for installing Codex hooks, adding guardrail rules, and proving those rules block matching tool calls. Run it through `npx -y @samirosamsam/aim@latest` so the workflow works from any Codex workspace. When developing AIM itself, use `node ./bin/aim.js` from the repo root. Do not invent final guardrail JSON by hand when the CLI can compile, install, or validate it.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
1. Install or refresh the Codex `PreToolUse` hook before claiming enforcement is active:
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
npx -y @samirosamsam/aim@latest setup --json
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
If Codex reports that hooks need review, tell the user to run `/hooks`, inspect the AIM hook, and trust it. Do not claim active enforcement until the hook is trusted and a proof call blocks.
|
|
19
|
+
|
|
20
|
+
2. Add the user's requested block as a Codex guardrail rule:
|
|
21
|
+
|
|
22
|
+
```bash
|
|
23
|
+
npx -y @samirosamsam/aim@latest rule add "<what the user wants to prevent>" --json
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
Examples:
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
npx -y @samirosamsam/aim@latest rule add "empêche git push" --json
|
|
30
|
+
npx -y @samirosamsam/aim@latest rule add "empêche de modifier package.json" --json
|
|
31
|
+
npx -y @samirosamsam/aim@latest rule add "empêche les calls GitHub qui ajoutent des collaborators" --json
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
3. Prove the guardrail with a representative hook input before reporting success. Pick the proof that matches the rule:
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
printf '%s' '{"tool_name":"Bash","tool_input":{"command":"git push origin main"}}' \
|
|
38
|
+
| npx -y @samirosamsam/aim@latest hook pre-tool-use
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
printf '%s' '{"tool_name":"apply_patch","tool_input":{"command":"*** Begin Patch\n*** Update File: package.json\n@@\n*** End Patch\n"}}' \
|
|
43
|
+
| npx -y @samirosamsam/aim@latest hook pre-tool-use
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
printf '%s' '{"tool_name":"mcp__github__add_collaborator","tool_input":{"owner":"tototozip","repo":"AIM","username":"someone"}}' \
|
|
48
|
+
| npx -y @samirosamsam/aim@latest hook pre-tool-use
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
The proof must return `permissionDecision: "deny"` for the blocked case. If it does not, report the blocker instead of saying the rule is installed.
|
|
52
|
+
|
|
53
|
+
4. Use `rule list` when you need to show what is active:
|
|
54
|
+
|
|
55
|
+
```bash
|
|
56
|
+
npx -y @samirosamsam/aim@latest rule list --json
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
## Advanced Commands
|
|
60
|
+
|
|
61
|
+
Use `capture`, `authorize`, `compile`, `add`, or `check` only for lower-level policy debugging. The normal public workflow is `setup`, `rule add`, proof, report.
|
|
62
|
+
|
|
63
|
+
```bash
|
|
64
|
+
npx -y @samirosamsam/aim@latest capture \
|
|
65
|
+
--provider github \
|
|
66
|
+
--tool list_repository_collaborators \
|
|
67
|
+
--args '{"owner":"tototozip","repo":"AIM"}' \
|
|
68
|
+
--effect deny \
|
|
69
|
+
--agent codex \
|
|
70
|
+
--connection github:prod \
|
|
71
|
+
--json
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
If a command returns `questions`, ask for the missing command, file path, provider, resource pattern, or access level before writing enforceable policy. Use `--force` only when the user explicitly accepts a broad or ambiguous rule.
|
|
75
|
+
|
|
76
|
+
## Scope
|
|
77
|
+
|
|
78
|
+
- For Codex enforcement, prefer `rule add` over `compile`/`add`; it writes rules intended for the `PreToolUse` hook.
|
|
79
|
+
- Prefer narrow resource patterns over `*`.
|
|
80
|
+
- Codex hook guardrails are default-allow: no matching block means the tool call proceeds.
|
|
81
|
+
- Treat `deny` as higher priority than `approval`, and `approval` as higher priority than `allow`.
|
|
82
|
+
- For write, delete, admin, private, finance, HR, legal, or shared-secret access, prefer `approval` or `deny` unless the user explicitly asks for allow.
|
|
83
|
+
- Do not request or store SaaS tokens. AIM policy rows reference agent UIDs, connection IDs or patterns, tools, resources, access, and effects only.
|
|
84
|
+
- AIM currently guards supported Codex `PreToolUse` surfaces: Bash, `apply_patch`, and MCP tools. Do not claim it blocks browser, WebSearch, or unsupported tool paths.
|
|
85
|
+
|
|
86
|
+
## Output Shape
|
|
87
|
+
|
|
88
|
+
When reporting results to a user, show the hook path, policy path, and grant rows that matter: `agentUid`, `connectionId`, `toolPattern`, `resourcePattern`, `access`, `effect`, and `reason`. Call out any broad wildcard, unresolved question, or hook trust requirement before suggesting the rule is active. Never say enforcement is active unless a representative hook test returned `permissionDecision: "deny"`.
|