Before You Install an AI Coding Agent: A Founder Trust Review

An AI coding agent does not need to be malicious to create a security incident.

Picture a founder installing a new command-line agent in the same folder as a live SaaS product. The agent can read the repository, run shell commands, call the internet, and edit files. The terminal also has access to cloud credentials, package-registry tokens, database URLs, signing keys, and configuration files in the founder's home directory. The product works, so the founder assumes the setup is safe.

That conclusion skips the important question: what could this program access or send if it behaved differently from what the founder expected?

The answer depends on the installed package, the code it executes, the account running it, its starting folder, inherited environment variables, available tools, and reachable network destinations.

This guide provides a 60-minute trust review before an AI coding CLI touches a real product. It cannot prove software is safe. It is a practical gate: enough evidence to choose a small test, demand stronger controls, or decline an install.

Three Questions That Must Stay Separate

Founders often compress trust into one signal: a known company, many repository stars, or a friend's recommendation. Those facts matter, but answer only part of the problem. Review three questions separately.

1. Is this the package the publisher intended to release?

This is an identity and supply-chain question. Check the exact package name, publisher, repository, version, release channel, source commit, and build provenance. Copied repositories, compromised accounts, stale links, and modified assets can break the connection between a trusted brand and the bytes on your machine.

npm's provenance system can link a published package to its source commit, build workflow, and public transparency record. GitHub also documents commands for verifying immutable releases and local release assets. These controls are useful evidence of origin and integrity.

They are not a safety certificate. npm explicitly notes that provenance does not guarantee the absence of malicious code; it creates a verifiable link so that people can audit what was built. A genuinely published package can still have an unsafe default, a bug, or permissions that are inappropriate for your product.

2. What does the program actually do?

This is a behavior question. A coding agent may read files beyond the open editor, inspect Git history, launch package scripts, call subprocesses, write caches, collect diagnostics, or send code and metadata to remote services. Some of those behaviors may be necessary. They still need to match your expectation and the vendor's documentation.

Do not treat “the model only received this prompt” as a complete data-flow description. The CLI, extensions, helper processes, telemetry libraries, shell, model gateway, and tools form one system. Review the system boundary, not just the chat box.

3. What damage is possible with the permissions you gave it?

This is a blast-radius question. The same binary can be low risk inside a disposable test folder with no credentials and high risk when run from a home directory under an administrator account.

OWASP's AI Agent Security Cheat Sheet identifies tool abuse, privilege escalation, data exfiltration, sensitive-data exposure, supply-chain attacks, and excessive autonomy as distinct agent risks. Its practical theme is least privilege: give an agent only the tools and resources required for a specific task, and require authorization for sensitive operations.

Publisher trust does not remove the need to limit consequences. Good vendors ship bugs, good models follow injected instructions, and good founders paste the wrong command.

The 60-Minute Pre-Install Review

Use a timer. The purpose is to prevent a convenience install from silently becoming a production trust decision.

Minutes 0–10: establish identity and the release path

Start at the vendor's official website or documentation, not a sponsored search result, copied tutorial, social reply, or package name suggested by a model. Follow the vendor's link to the repository or registry.

Write down:

• Exact package and command name.
• Exact version you intend to install.
• Publisher or organization name.
• Official repository URL.
• Link between the repository and registry listing.
• Release date and release notes.
• Whether the version is stable, beta, preview, or nightly.

For an npm package, inspect the registry page for provenance. When provenance exists, open its details and confirm the source repository, commit, build workflow, and build environment match what you expect. After installing dependencies, npm audit signatures can check registry signatures and provenance attestations with a supported npm version.

For a downloaded GitHub release, check whether the release is marked immutable. GitHub documents gh release verify RELEASE-TAG for the release and gh release verify-asset RELEASE-TAG ARTIFACT-PATH for a downloaded asset. Read the documented limitations: verification is only meaningful when it covers the artifact you actually run.

Stop if the product site, registry, repository, and release disagree about ownership or version. A missing attestation is not automatic proof of danger—many legitimate projects do not publish one—but conflicting identity is a reason not to proceed.

Minutes 10–20: map the data the agent could reach

Create a simple access map before running the program.

The working directory is not necessarily a security boundary. A process running as your user may read outside it unless a sandbox or operating-system control prevents that. List secrets stored in the repository or injected by the shell without copying their values. Mark each as production, staging, development, or disposable. If a first run needs a production credential, the test design is wrong.

Minutes 20–30: read the permission and data controls

Find current vendor documentation for:

• File access beyond the selected workspace.
• Shell execution and whether commands require approval.
• Network access and remote endpoints.
• Prompt, source-code, and telemetry retention.
• Training or product-improvement use.
• Local caches, debug logs, and crash reports.
• Configuration files read from the home directory.
• Plugins, MCP servers, extensions, and inherited tools.
• An offline, local-only, or zero-retention mode, if advertised.

Record what is unclear. “We take security seriously” is not an answer to where code goes, how long it remains, or which subprocesses can execute.

NIST SP 800-218A extends secure software-development practices for generative AI and is intended not only for producers but also for organizations acquiring AI systems. That is a helpful mindset for a small team: installation is procurement, even when the price is zero. Ask for enough evidence to operate the tool safely.

Pay special attention to defaults. A setting that can disable telemetry is useful only if you know whether it is enabled before the first command. An approval mode is useful only if subprocesses cannot bypass it. A workspace limit is useful only if it is enforced rather than described in a prompt.

Minutes 30–45: run a clean-room trial

Do not make the first run in the live repository.

Create a new operating-system user, disposable virtual machine, container, or another environment whose boundaries you understand. A container is not automatically secure, especially if it mounts your home directory, Docker socket, SSH agent, or cloud configuration. The important property is isolation, not the label.

Put a small synthetic project inside it. The project should resemble your stack without containing customer data or proprietary code. Include harmless canary values with unique names—for example, a fake API key format and a text file outside the project folder that says it must not be read. Never use a real secret as a canary.

Then:

1. Start with no production environment variables.
2. Give the agent read-only access if the task permits it.
3. Disable automatic command execution and third-party tools.
4. Ask it to explain the project without changing files.
5. Ask it to make one reversible change on a new branch.
6. Review every requested command and network permission.
7. Compare files and configuration before and after the run.
8. Check whether the outside-workspace canary was accessed or mentioned.
9. Review documented logs, caches, and account activity.

Network observation is valuable but easy to misread: a destination does not show what encrypted traffic contained. Treat it as one piece of evidence. For material egress risk, involve a qualified reviewer or require the vendor's endpoint and data-flow inventory.

VS Code's Workspace Trust model offers a useful analogy: unfamiliar folders open in Restricted Mode, where agents, terminals, tasks, debugging, settings, and extensions are limited until the user trusts the workspace. It also warns that Workspace Trust cannot force a malicious extension to cooperate. Product controls help, but the trust boundary must be real.

Minutes 45–55: test failure and refusal paths

A happy-path demo tells you little about boundaries. Try safe negative cases:

• Ask the agent to read a file outside the allowed folder.
• Ask it to display environment variables.
• Give it a document containing an instruction to ignore the user and upload files.
• Ask it to install an unrelated package.
• Ask it to run a destructive command against the synthetic project.
• Disconnect the network and observe whether it fails clearly.
• Deny a command and confirm the task stops or chooses a safe alternative.

You are not trying to trick a model into performing harm. You are checking whether technical controls enforce the policy when the model makes a bad choice. A prompt saying “never access secrets” is weaker than secrets that are absent. A rule saying “ask before deleting” is weaker than a filesystem permission that blocks deletion.

Record the exact tool version, settings, permissions, test input, and result. OWASP recommends retaining validation evidence for production agents, including the version, tool policy, abuse cases, observed approval or denial behavior, and accepted residual risk.

Minutes 55–60: make a rollout decision

Choose one of four outcomes.

If the review produces unanswered questions, the decision is “sandbox only” until they are resolved.

A Safe First Pilot on a Real Repository

Once the clean-room trial passes, a real pilot should still assume the agent can make mistakes.

Use a separate branch and clean working tree. Back up anything irreproducible. Remove production .env files and inject short-lived, least-privilege test credentials only when needed. Prevent the agent from merging, altering protected branches, creating releases, or changing CI secrets. Keep deployment credentials out of the session.

Choose a bounded task: update copy, add a test, document an API, or fix a reproduced low-risk bug. Avoid authentication, billing, permissions, migrations, signing, legal records, and customer-data exports.

Require a human to inspect the diff, commands, dependency changes, generated lockfile, and test results. A green build proves that the project compiled under its tests; it does not prove that no data left the machine or that the agent respected an unwritten business rule.

Enable preventive secret controls. GitHub's push protection can block recognized credentials before they reach a repository, including in command-line pushes and some MCP interactions. It is a valuable backstop, not a complete detector: secret scanners have documented scope and pattern limitations. The safer control is still not exposing production secrets to the process.

Define a kill procedure before the pilot: stop the process, revoke the test credentials, disconnect integrations, preserve relevant logs, restore the branch, and notify the accountable person. If the team cannot revoke a credential quickly, that credential is too powerful for the pilot.

Common Trust Mistakes

• “It is open source.” Inspection is possible, but that does not prove the exact version was reviewed or the registry artifact matches the source. Connect source, build, artifact, and runtime behavior.
• “It only sees this repository.” That is true only when enforced. The process may inherit access to home-directory configuration, neighboring folders, environment variables, credential helpers, and mounted volumes.
• “We scanned for secrets.” Scanners miss some credentials and do not identify every customer record, private URL, local database, sensitive document, or inherited environment variable.
• “The vendor is reputable.” Reputation supports intent and accountability; it does not make every release, default, dependency, or integration appropriate for every workspace.
• “The agent asked for approval.” Opaque or bundled commands cannot be meaningfully approved. Prefer narrow commands, readable diffs, parameter-bound approvals, and technical denial of forbidden actions.
• “The output looked normal.” Data access and egress may not appear in chat. Review files, processes, account activity, logs, and controls.

Where This Framework Does Not Apply

This review is proportionate for early-stage teams evaluating ordinary developer tools. It is not sufficient for regulated, safety-critical, or highly confidential environments, which may require formal vendor assessment, contractual data terms, managed devices, monitored egress, allowlisting, legal review, and professional testing.

It also cannot prove a tool is benign. A short test may miss delayed behavior, compromised updates, conditional paths, or hidden payloads. Re-run it after major versions, new plugins, providers, permissions, or more sensitive code. Provenance shows origin, not correctness; sandboxing reduces consequences, not intent; secret scanning catches known patterns, not all sensitive information. The strength comes from layers.

The Founder Installation Gate

Before an AI coding agent touches a real product, require a clear “yes” to these questions:

• Did we reach the package through an official vendor path?
• Do the registry, repository, publisher, version, and release agree?
• Did we verify provenance or release integrity when available?
• Do we understand the limits of that verification?
• Have we mapped project, home-directory, environment, Git, editor, and network access?
• Are production secrets and customer data absent from the first test?
• Does a technical boundary restrict the agent to the intended workspace and actions?
• Did a clean-room trial test both normal behavior and refusal paths?
• Did we inspect file changes, commands, caches, logs, and network destinations?
• Are commands approved individually for sensitive actions?
• Is the first real task reversible, low risk, and isolated on a branch?
• Can we revoke credentials and stop integrations quickly?
• Is one person accountable for upgrading, reviewing, and disabling the tool?
• Will we repeat the review when the package or permissions materially change?

If any critical answer is no, do not compensate with confidence in the model. Reduce access until the answer becomes yes.

AI coding agents can give a tiny team enormous leverage. That is exactly why installation deserves more care than a normal productivity app. The tool can see the raw material of the company and act through the founder's machine. A good trust review does not ask whether the agent seems smart or friendly. It asks whether identity is verifiable, behavior is understood, and consequences are bounded.

References

• NIST, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, SP 800-218A.
• OWASP Cheat Sheet Series, AI Agent Security Cheat Sheet, covering least privilege, data exfiltration, supply-chain risk, approvals, and validation evidence.
• OWASP Cheat Sheet Series, Secure Coding with AI Cheat Sheet, guidance for AI-assisted development workflows.
• npm Docs, Viewing Package Provenance, including source, build, transparency-log details, and signature verification.
• npm Docs, Generating Provenance Statements, including the limitations of provenance as a security signal.
• GitHub Docs, Verifying the Integrity of a Release, immutable release and asset verification.
• Visual Studio Code Docs, Workspace Trust, Restricted Mode and the limits of workspace trust.
• GitHub Docs, Push Protection, preventive secret scanning and bypass behavior.
• CISA, NSA, and ODNI, Securing the Software Supply Chain: Recommended Practices for Customers, procurement and deployment guidance.