Agent security boundary
Skill alinafe82/cognitive-deadlift/skills/agent-security-boundary
AI coding skills, hooks, and plugins that keep developers thinking instead of autopiloting
npx -y skills add alinafe82/cognitive-deadlift --skill agent-security-boundaryAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Review security boundaries for agent skills and tool-using workflows. Use when a skill, hook, script, adapter, or agent workflow touches tools, shell commands, file writes, secrets, private data, external documents, network calls, permissions, or destructive actions. NOT for ordinary style edits or non-tooling docs with no data or permission boundary.
SKILL.md
4.1 KB, as published. Nobody here has run it
Agent Security Boundary
Purpose
Prevent agent workflows from widening permissions, leaking data, or trusting hostile context.
Preserves
Security judgment for tool-using agents.
Required Evidence
- Tool, file, network, or permission surfaces touched.
- Data sensitivity and trust boundaries.
- User approvals or destructive action requirements.
- Prompt-injection and untrusted-content exposure.
Failure Signs
- A skill lets untrusted docs instruct tool use.
- Secrets or private data can enter prompts, logs, examples, or fixtures.
- Destructive or permission-widening commands lack approval gates.
When To Use
- A skill or script uses shell commands, APIs, files, or external documents.
- A change touches secrets, credentials, private data, or generated logs.
- A workflow can delete, publish, deploy, send, or mutate external state.
- Runtime permissions or adapter capabilities change.
When Not To Use
- Pure copy edits with no tool, data, or permission surface.
- General code review with no agent boundary concern; use diff-interrogation.
- Release metadata review without security-sensitive changes; use release-readiness.
Inputs Expected
- Skill, script, hook, adapter, or workflow diff.
- Tools and permissions available to the agent.
- Data sources, trusted and untrusted inputs, and output destinations.
- Existing approval and rollback rules.
Output Expected
Workflow:
Tools and data:
Trust boundaries:
Prompt-injection risks:
Permission or destructive risks:
Required guardrails:
Decision:
Process
- Map every tool, file, network, and external-state boundary.
- Classify data sensitivity and untrusted inputs.
- Identify how prompt injection or misleading context could steer tool use.
- Check approval gates for destructive, permission-widening, or external-send actions.
- Recommend guardrails, rejection, or targeted validation before merge.
Quality Bar
A good boundary review names concrete paths by which an agent could leak data, mutate state, or follow untrusted instructions, plus the guardrail that blocks each path.
Examples
Simple case: Review a skill that tells the agent to read local .env files for setup. The skill should flag secret exposure risk.
Complex case: Review an agent workflow that reads user-uploaded docs and runs shell commands based on extracted instructions. The skill should treat uploaded docs as untrusted content.
See examples/simple.md and examples/edge-case.md.
Failure Modes
- Required files missing: state what could not be checked and ask for the smallest missing artifact.
- Context ambiguous: list the plausible interpretations and pick the one that affects the decision most.
- Permissions missing: name the command, file, or approval needed without inventing results.
- Tests or checks fail: report the failure and do not recommend acceptance until the failure is understood.
- Unsafe request: refuse the unsafe step and offer a safe review or evidence-gathering path.
- Claim cannot be verified: mark it as unsupported and require evidence or limitation language.
Safety And Privacy
Do not request or expose secrets, tokens, private keys, customer records, private employer details, personal data, or production credentials. Use redacted examples and require approval before destructive, external-send, permission-widening, or publication actions.
Anti-Slop Rules
- Do not approve a skill, claim, release, or workflow on confident wording alone.
- Do not treat file presence as evidence of substance.
- Do not invent command results, runtime behavior, usage evidence, or reviewer approval.
- Do not broaden scope to make the recommendation sound more useful.
- Do not hide missing evidence in a generic summary.