An AI-agent security baseline should be small enough to run on every repository and broad enough to catch the ways an agent can move from text to action.
The OWASP Agentic AI threats and mitigations guide is a useful threat-model reference. The checklist below turns that kind of model into questions a development team can answer before an agent is trusted with a repository or credential.
1. Identity and scope
Every agent should have a named purpose, owner, environment, and permission boundary. Do not give a general-purpose coding agent production credentials just because it can use them.
2. Tools and side effects
List every tool the agent can call. Mark which tools read, write, execute, publish, deploy, or change permissions. Require approval for high-impact actions and validate arguments before dispatch.
3. Prompt and context boundaries
Repository files, issue descriptions, web pages, tool results, and retrieved documents may contain attacker-controlled instructions. Treat them as data. Do not let text silently rewrite system policy or tool permissions.
4. Secrets and credentials
Use short-lived credentials, narrow scopes, and separate identities for development, CI, and production. Keep secrets out of prompts, tool descriptions, logs, screenshots, and generated reports.
5. Memory and persistence
Decide what an agent can remember, who can change that memory, and how a team can inspect or delete it. A poisoned memory entry can influence later runs long after the original input disappears.
6. Dependencies and skills
Pin packages, skills, actions, and agent manifests. Review install scripts and external URLs. An agent should not be allowed to add an unreviewed capability merely by editing a markdown file.
7. CI and release controls
Use least-privilege workflow permissions, isolate untrusted pull requests, pin third-party Actions, and keep publish jobs behind protected environments. Preserve complete machine-readable security reports.
8. Evidence and recovery
Log the decision, not unnecessary sensitive content. Keep enough evidence to explain why a call was allowed or denied, then make revocation and rescan straightforward.
A baseline you can run today
~~~bash
npx ship-safe@latest audit . --no-ai
npx ship-safe@latest ci . --threshold 80 --sarif ship-safe.sarif
~~~
Use the first command for local feedback and the second as a repeatable merge gate. The exact threshold is a team decision; the important part is that it is explicit and reviewed.
What this baseline does not claim
A scanner cannot prove that an agent is safe in every future context. A clean result means the checked repository and configuration did not match the covered rules at that point in time. It does not replace threat modeling, access review, runtime monitoring, or human judgment for consequential actions.
That limitation is useful to state. Security tools become more trustworthy when their coverage and boundaries are visible.
Start with the Ship Safe security model, review the benchmarks and limitations, and follow the web app guide when your team needs shared history and ownership.