This security guide explains how we review AI agent skills before trust recommendations. The goal is practical: help teams move faster without accepting hidden operational risk.
Grade labels summarize risk density, not feature richness. We score implementation behavior, permission requirements, and operational blast radius. A skill with fewer features can rank safer than a feature-rich one if it keeps strict boundaries and predictable failure modes.
Network diagnostics
Some security searches come from log fragments rather than normal product intent. When a query contains a proxy hostname, a local inspection domain, or an unfamiliar outbound destination, the right response is triage inside the security guide, not a standalone keyword page that could distract from the directory topic.
Signal: A log, trace, or package output shows a MITM-looking hostname such as default.mitmproxy.hub.ace-research.openai.org.
Review response: Treat it as an environment-specific routing signal, not as a public integration target. Verify the runtime owner, proxy policy, and whether the request carried sensitive headers.
Signal: A skill contacts a domain that is not documented in its README, install command, or permission notes.
Review response: Block promotion until the destination is explained, allowlisted, and tested with redacted inputs. Silent telemetry should lower the trust score.
Signal: A request includes API keys, cookies, bearer tokens, repository contents, or local file snippets.
Review response: Fail the review unless the transfer is essential, explicit, and user-approved. Logs should mask tokens before they leave the local machine.
MCP package risk update
Users who search exact MCP package names are often trying to paste commands directly into Claude Code, Cursor, VS Code, or another client. A security guide should intercept that moment and convert it into a source, permission, and action-boundary review.
Signal: The install command looks like a known MCP package but the namespace, maintainer, or registry source is different.
Review response: Pause installation and verify the package from official docs, registry metadata, and repository ownership before it reaches a client config.
Signal: A server requests local read/write access, broad path scopes, or the ability to search outside the working project.
Review response: Limit allowed directories, start read-only where possible, and require review before the server mutates files or touches private folders.
Signal: A server can fetch URLs, call APIs, upload data, or combine browser/session state with private prompts.
Review response: Document outbound destinations and block use with secrets, customer data, or unpublished content until the path is explicitly approved.
Signal: A server can delete branches, run SQL writes, change access controls, publish deploys, or trigger external workflows.
Review response: Keep those actions human-approved one at a time, and require preview evidence before production expansion.
Skills that execute arbitrary code from untrusted or weakly validated input.
Shell execution patterns where user input can alter command intent.
Actions that can irreversibly delete data or damage runtime state.
Unapproved data transfer from local context to external endpoints.
Reads from locations that commonly contain credentials or private data.
Hardcoded secrets or logging/output paths that expose sensitive tokens.
Unauthorized mechanisms that survive session boundaries.
Attempts to obtain elevated privileges or bypass permission boundaries.
Strong security review is process-driven. We use a repeatable flow: static pattern checks, behavior simulation, permission scope validation, and rollout-readiness review. This ensures teams can compare skills consistently, not rely on subjective impressions.
Teams that skip one of these steps usually pay later with brittle automation, unclear ownership, or emergency rollbacks during peak workload windows.
Imagine your team wants to adopt a skill that automates data pull plus content update. Day one, define one measurable outcome and one explicit stop condition. Day two, run preview-only against a narrow dataset. Day three, classify errors by root cause rather than generic logs. Day four, patch guardrails for repeated failure classes. Day five, run one controlled replay and compare baseline metrics.
If throughput improves but error severity rises, promotion should be blocked. If throughput improves and error severity drops or remains stable, promote gradually with bounded scope. This is how teams avoid false confidence from raw speed gains.
Yes. Scoring is a risk signal, not an absolute safety guarantee. Always review permission scope and deployment context.
Run preview-first validation with fixed pass/fail checks, log failure evidence, and confirm rollback ownership.
Refresh after upstream updates and run a scheduled monthly drift review for production-critical skills.
They create the largest blast radius when misused, especially in automation chains with access to local files and external APIs.
A MITM-looking hostname in logs usually points to environment-specific proxy routing or network inspection. Do not create an integration around it. Instead, verify the runtime owner, confirm whether the skill intentionally made the request, and ensure no secrets or private files were sent through that path.
Adopt fewer skills at once, enforce explicit ownership, and require evidence-backed acceptance before production expansion.
The safest adoption pattern is still preview-first execution with clear ownership. Use this guide to structure decisions, reduce ambiguity, and keep production rollouts predictable.