# AI use cases for Agent Security (solongate/agent-security)

Repo: [solongate/agent-security](https://github.com/solongate/agent-security) | Use cases: 4 | Page: https://dedupedai.com/use-cases/solongate-agent-security/

SolonGate Agent Security is a local, open-source Go gateway that checks AI coding agent tool calls against policy, detects secrets, and writes an on-device audit trail.

This file holds every use case of this repo. Each one starts with a "## " heading and ends with its URL.

- Stop an AI coding agent from reading your .env secrets: https://dedupedai.com/use-cases/solongate-agent-security/block-agent-access-to-env-secrets/
- Lock files so a coding agent cannot delete or edit them: https://dedupedai.com/use-cases/solongate-agent-security/lock-files-against-agent-edits/
- Confine a coding agent to one project folder on Linux: https://dedupedai.com/use-cases/solongate-agent-security/confine-agent-to-one-project-on-linux/
- Review every tool call an AI coding agent made: https://dedupedai.com/use-cases/solongate-agent-security/review-agent-tool-call-audit-trail/

## How to stop an AI coding agent from reading your .env secrets with Agent Security

Repo: [solongate/agent-security](https://github.com/solongate/agent-security) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README

Install the local guard so an agent is refused when it reaches for a .env file and every decision is logged.

**Who it is for:** A developer who lets Claude Code or Codex work in a repo that holds API keys in a .env file and wants the agent blocked from them.

**The problem:** An agent working in a project can open a .env file and read credentials it does not need for the task.

**The outcome:** The agent's attempt to read .env is refused by the guard, the refusal is recorded in the local audit trail, and the agent reports the block instead of working around it.

### Steps

1. `git clone https://github.com/solongate/agent-security.git`
2. `cd agent-security`
3. `./scripts/shell/install.sh`
4. Open a new terminal, then start Claude Code or Codex in your project.
5. Ask the agent to read the .env file, then run `solongate audit` to confirm the refusal was logged.

### Prompt to paste into your agent

```text
Install the SolonGate guard from https://github.com/solongate/agent-security by running ./scripts/shell/install.sh in a fresh terminal, then start <agent> in <project-path> and ask it to read the .env file. Expected output: the guard refuses the read and the agent reports the refusal. Verify by running `solongate audit` and confirming a deny entry for .env exists in ~/.solongate/local-logs/solongate-audit.jsonl.
```

### Caveat

The guard only covers agents it hooks into (the README names Claude Code, Codex, OpenCode and Antigravity), and hooks apply only to sessions started after install.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/solongate-agent-security/block-agent-access-to-env-secrets/

## How to lock files so a coding agent cannot delete or edit them with Agent Security

Repo: [solongate/agent-security](https://github.com/solongate/agent-security) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README

Put an OS-level lock on key files and start the agent inside that protection so it cannot remove them.

**Who it is for:** A developer whose agent once deleted or overwrote a file they care about and who wants that file out of reach regardless of how the agent names it.

**The problem:** Pattern rules match the words in a tool call, so a script or compiled program the agent writes can still delete a file without its name appearing in a call the guard reads.

**The outcome:** The protected file stays intact while the agent runs under `solongate run`, and `protect list` shows what is actually holding each path.

### Steps

1. Complete the guard install from the repo README with `./scripts/shell/install.sh` and open a new terminal.
2. `solongate protect ~/game/game.c`
3. `solongate protect list`
4. `solongate run -- claude`
5. Ask the agent to delete the protected file, then confirm it still exists.

### Prompt to paste into your agent

```text
Using the SolonGate repo at https://github.com/solongate/agent-security, run `solongate protect <file-path>` and then `solongate run -- claude` in <project-path>. Expected output: the protected file cannot be deleted or written by the agent. Verify by running `solongate protect list` and checking that <file-path> is listed with the lock it is actually held by.
```

### Caveat

On Linux the unprivileged fallback is chmod 0444, which stops writes but not rm, and the README says `protect list` reports that rather than printing protected.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/solongate-agent-security/lock-files-against-agent-edits/

## How to confine a coding agent to one project folder on Linux with Agent Security

Repo: [solongate/agent-security](https://github.com/solongate/agent-security) | Difficulty: Advanced | Time: 60 minutes | Basis: From the README

Start an agent in a closed box where only one project directory exists and nothing else on the machine is visible.

**Who it is for:** A developer on Linux who runs an agent across several client repositories and wants one agent session to see only one of them.

**The problem:** An agent started normally can reach home directories, SSH keys, other projects and credentials of installed tools.

**The outcome:** The agent works inside a box where the project is at /workspace and other paths are absent, with the box's network setting chosen per box.

### Steps

1. Install bubblewrap so that `bwrap` is available on the machine, since the README says a missing one is a refusal.
2. Complete the guard install with `./scripts/shell/install.sh` and open a new terminal.
3. `solongate sandbox list`
4. `solongate sandbox 001 claude`
5. `solongate sandbox --explain 001`

### Prompt to paste into your agent

```text
On a Linux machine with bwrap installed, use the SolonGate repo at https://github.com/solongate/agent-security to create a sandbox box from the TUI Sandbox section for <project-path>, then run `solongate sandbox 001 claude`. Expected output: the agent starts with the project at /workspace and home directories absent. Verify by running `solongate sandbox --explain 001` and checking that the listed contents match the project only.
```

### Caveat

The sandbox is Linux only, and the box's network stays on when the agent needs its model, so content leaving over the wire is handled by the DLP and egress layers rather than by the box.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/solongate-agent-security/confine-agent-to-one-project-on-linux/

## How to review every tool call an AI coding agent made with Agent Security

Repo: [solongate/agent-security](https://github.com/solongate/agent-security) | Difficulty: Beginner | Time: 15 minutes | Basis: From the README

Read the local audit trail and watch live tool calls to see what an agent tried and what the guard decided.

**Who it is for:** A developer or team lead who wants a record of what an AI coding agent did in a session before merging its work.

**The problem:** Without a record, it is hard to tell which files an agent touched, which calls were refused, and whether a secret was involved.

**The outcome:** A list of allowed and denied tool calls from the session, read from the local audit file and the live tail.

### Steps

1. Complete the guard install with `./scripts/shell/install.sh` and open a new terminal.
2. Run an agent session in the project, such as `solongate run -- claude`.
3. `solongate audit`
4. `solongate watch`
5. Check that each decision has a matching line in ~/.solongate/local-logs/solongate-audit.jsonl.

### Prompt to paste into your agent

```text
Using https://github.com/solongate/agent-security, run `solongate audit` after a session with <agent> in <project-path>. Expected output: a list of tool calls with their allow or deny decisions. Verify that ~/.solongate/local-logs/solongate-audit.jsonl contains one JSON object per decision, matching what the audit view shows.
```

### Caveat

The audit trail records decisions the guard made, so it only shows tool calls that passed through a hook in a session started after install.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/solongate-agent-security/review-agent-tool-call-audit-trail/