Software trust evidence
Security review for the AI coding agents in your stack
The problem
AI coding agents now add packages, edit manifests, and run tools across your repos, often before a human looks. Each installed agent, skill, and MCP server declares its own filesystem, network, and secret scope, and that capability surface changes every time someone installs a new pack. Your security team needs to see what these agents can actually reach, decide what to accept, and keep a record an outside reviewer can read.
Why current tools miss it
Scanners read source and dependencies, not the agent runtime that introduced them, so the agent itself is never the subject. GRC platforms hold questionnaire answers and policy text, with no view of the skills and MCP servers installed on a developer's machine. SBOMs and trust centers describe shipped artifacts, not the executable-capability evidence an agent declares or the human decision made about it.
How OpenSoyce records the evidence
OpenSoyce captures each installed agent, skill, and MCP server as an evidence subject: its name, version, source, declared permissions, tools, MCP connections, and digest. It surfaces capability review signals such as broad filesystem access, declared network access, secret-style scopes, and auto-updating sources, each one a prompt to look, never a verdict. It records the human risk decision around any finding, including an owner and an expiry, without hiding the original signal, and the same evidence flows into package and CI signals, a signed packet, a buyer-readable dossier, a JSON export, and signed webhook events.
The boundary
OpenSoyce preserves and explains this evidence; it does not decide whether an agent is safe. Installed is not trusted, a declared permission is not an approved one, and the absence of a signal is not a clearance. The signature and artifact binding attest integrity and origin, and your policy decides trust.