← Oximy Reality ChecksCONTENT HISTORY

Update to Oximy Reality Checks

Snapshot Sep 30, 2026 · 23:16 UTC · version 0.1.2

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Compare an agent's configured capabilities with observed tool use and propose a least-privilege configuration for defined workflows. Use when someone wants to reduce agent permissions, MCP access, filesystem scope, network reach, or approval bypasses. Do not apply permission changes or infer safe denial from non-use alone.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 266
    },
    {
      "relative_path": "evals/cases.json",
      "size_in_bytes": 853
    },
    {
      "relative_path": "references/capability-model.md",
      "size_in_bytes": 993
    },
    {
      "relative_path": "scripts/summarize_tool_use.py",
      "size_in_bytes": 2682
    }
  ],
  "name": "right-size-my-agent",
  "skill_md_contents": "---\nname: right-size-my-agent\ndescription: Compare an agent's configured capabilities with observed tool use and propose a least-privilege configuration for defined workflows. Use when someone wants to reduce agent permissions, MCP access, filesystem scope, network reach, or approval bypasses. Do not apply permission changes or infer safe denial from non-use alone.\nlicense: MIT\n---\n\n# Right-Size My Agent\n\nDerive a proposed permission envelope from actual work, then challenge it with the workflows the agent must still perform.\n\n## Boundary\n\n- Produce a reviewable proposal; do not change permissions, credentials or agent configuration.\n- Treat configured capability, observed use and required capability as separate states.\n- Do not remove access solely because it is absent from a limited trace window.\n\n## Required inputs\n\n- The agent and workflows being scoped.\n- Current configuration or a reliable capability inventory.\n- A representative trace window, including exceptional work when available.\n\nIf traces are not representative, produce an exposure map and evidence plan rather than a least-privilege recommendation.\n\n## Workflow\n\n1. Define the unit: one agent identity, environment, user or service account, and named workflow set. Do not aggregate identities with different authority.\n2. Inventory configured capability across tools, MCP servers, commands, filesystem roots, network destinations, credentials, approval policies, and downstream service roles.\n3. Run `scripts/summarize_tool_use.py` on available JSONL traces. Verify high-risk and ambiguous calls in the raw evidence.\n4. Map each observed capability use to the workflow step it enabled. Label capability not observed, observed, or required-but-not-observed.\n5. Identify privilege gaps: write when read sufficed, broad path when one directory sufficed, reusable credential when one-action authorization sufficed, owner-level role when a narrower resource role sufficed, or external communication when a draft-only action sufficed.\n6. Propose the narrowest envelope that supports the named workflows. Include explicit approval gates and a break-glass path where removal would otherwise make legitimate exceptional work impossible.\n7. Run counterexamples against historical and anticipated tasks. State which tasks the proposal would block.\n8. Produce a reviewable patch or configuration diff, but do not apply it without explicit authorization. After any later application, rerun representative tasks and inspect denials.\n\nRead [references/capability-model.md](references/capability-model.md) before combining permissions across tools or identities.\n\n## Completion criterion\n\nEvery configured capability is accounted for; every retained high-risk capability maps to a named workflow or break-glass case; non-use is not treated as proof of safety to remove; counterexamples are recorded; and all proposed mutations remain unapplied unless separately approved.\n\n## Output\n\n1. Scope and trace coverage\n2. Configured capability map\n3. Observed use by workflow\n4. Excess or ambiguous privilege findings\n5. Proposed envelope and approval gates\n6. Tasks that may break\n7. Reviewable patch, if the format is known\n8. Validation plan and evidence limits\n"
}

SHA-256 of public snapshot: f4002c7d396d952bebc80500efa790286239bd926b045956d514b8cb58b24cc7