Security Resources

Choosing and checking a resource

Start with the job you want an agent to do. For a Docker Compose draft, search for Docker and open the generator's instructions; review the suggested services, volumes and environment placeholders against your project. A prompt template asks an agent to produce a draft. It does not install Docker, validate a deployment or establish that the output is ready for production.

Choose the resource type before installing anything. Instructions and prompts are text to read and adapt. MCP configurations can connect an agent to another service, and plugin examples may refer to packages that must be obtained separately. Read the actual commands and requested permissions. Use a disposable project and synthetic data for a first check; avoid adding credentials to downloaded examples.

Search and filter metadata help narrow the list, but a compatibility label is an intended target, not a recorded test result. Open the listing and follow its source link when one is provided. Check the upstream version, installation instructions and license before copying, modifying or sharing material. An author name or an MIT label alone does not establish who owns every included file.

If a source, license, package or required capability cannot be verified, keep the resource out of a production workflow until that gap is resolved. Report the listing URL and the missing information to SimplyUtils through the contact page. Include a small non-confidential example of any instruction that fails, along with the application and version you tested.

Security resources in this directory are review notes and instruction examples. They are not installed protection, a penetration test, or a certificate that an application is safe. Choose an entry by the boundary you need to inspect: trusted permissions, outgoing data, retrieved instructions, server access, or dependency selection. A single prompt cannot implement all of these boundaries. Read its example and limitations before copying any text into an assistant, and decide which part belongs in application code rather than in a model instruction.

For a first exercise, draw three boxes on paper: the person who authorizes a task, the assistant proposing actions, and the service executing those actions. Suppose the approved task is to read a fictional public note called N1 and summarize its opening time. The service should accept the authorized read and reject a proposed private-file read or message send. The expected outcome concerns the service decision, not whether the assistant promises to behave. Use invented identifiers and disposable data throughout this exercise.

The permission guide demonstrates exact comparisons against a trusted allowance. It deliberately does not normalize operating-system paths, resolve symbolic links, or validate a user identity. If your real service accepts filesystem paths, a passing toy identifier test is insufficient. Establish the allowed workspace and validate the resolved destination in the service handling the request. Check how archives, shortcuts, case differences and concurrent filesystem changes affect that boundary. Ask for specialist review when you cannot explain which component enforces it.

The redaction guide addresses a different question: what permitted information will actually leave a system? Its fictional pattern replaces a demonstration token and address. It does not identify every personal record or real credential. Start by removing unnecessary fields, then inspect both the proposed request and what is transmitted. A sanitized preview is ineffective if a retry, log, exception or attachment retains the original value. A redaction decision also cannot supply permission to disclose a record that was never authorized.

The prompt-injection guide separates a document's factual material from instructions embedded in that document. A public note may state an opening time and also demand an unrelated private action. The useful answer should cite the time while the service refuses the unauthorized action. Treat document delimiters as reading aids, not enforcement. Record proposed actions and actual service decisions separately. A friendly answer alone does not reveal whether a hidden tool request was attempted or whether an external destination received data.

The MCP access guide concerns the server accepting an assistant's requests. Its local example checks supplied fictional identity fields and workspace scope; it is not a token verifier. For a real deployment, determine which trusted component validates credentials, audience, expiration and permissions. Test a request for the wrong workspace as well as a valid one. Do not pass a credential to another service merely because a configuration example contains a token field. Inspect the server's actual implementation and current protocol documentation.

The dependency guide distinguishes needing a package, identifying it, checking available advisory information and deciding whether installation is appropriate. A matching package name and an empty advisory result do not establish safety. Review the exact version, source repository, installation scripts, license and permissions. A registry timeout leaves the evidence unavailable; it is not a clean scan. The directory does not install a package or run its scripts. Its examples use fictional package metadata so the decision process can be inspected without downloading unfamiliar software.

Compare related entries by the failure they cover rather than by strong titles or long checklists. If an assistant can send messages, both permission enforcement and outgoing-data minimization matter. If it can retrieve pages, document trust matters too. If it connects to a server, identity and scope must be checked there. Write a small list of accepted operations, forbidden operations and uncertain conditions for your own workflow. Give each condition an observable result and a responsible enforcement component before considering automation.

A useful review record includes the resource URL, the copied revision, the disposable input, the expected decision and the actual result. Include at least one permitted case, one refused case and one boundary case. For the note exercise, these could be reading N1, requesting a private note, and supplying a missing identifier. Keep failures and unknown outcomes visible. If the evaluator cannot observe a network request or service decision, record that limitation rather than replacing missing evidence with a successful-looking answer.

SimplyUtils supplies original commentary and fictional exercises alongside template text. Several templates were generated with an AI agent and have unconfirmed redistribution terms. A named application or dependency retains its own licensing and data-processing terms. Source attribution describes where text came from; it does not demonstrate that the instructions work in your setup. User-submitted material needs its own review. Do not infer ownership, security expertise, endorsement or verified integration merely from a listing being present in this directory.

Reading these pages and downloading their text does not execute the examples or submit your repository to a model. Using them elsewhere can have different consequences. An assistant may send prompts, files, attachments and tool results to its provider, and connected services can retain logs. Check those actual settings before using confidential material. Test with synthetic notes, invented addresses and credentials that cannot access anything. Keep genuine secrets out of screenshots and support messages, including when explaining why a redaction rule failed.

If an entry appears incomplete, identify the missing component precisely. A policy paragraph is not an executable authorization service; a JSON configuration is not proof that its package exists; a local comparison is not a live server test. Report the page URL, the relevant excerpt and a short redacted reproduction through the contact page. Search and category filters operate on listing metadata, so a missing search result can also reflect wording or an active filter. Clear filters before concluding that an entry has been removed.

• Prompt Injection Boundary Review Guide - A prompt-injection review guide separating document evidence from trusted action permissions. It does not make an agent immune to hostile instructions.
• Secret Redaction Review Guide - A redaction-review guide with invented token and address fixtures. It does not guarantee detection of real secrets or personal information.
• Agent Permission Policy Review Guide - A permission-review guide with a fictional allowlist exercise. It is not an installed sandbox or filesystem authorization service.
• MCP Server Access Review Guide - An MCP access-review guide with fictional audience and workspace checks. It does not deploy a server or validate real credentials.
• Dependency Selection Review Guide - A dependency-selection review guide with fictional package metadata. Registry and advisory checks do not establish package safety.