Rules & compliance

Rules that hold, and the evidence to prove it.

Set what agents may and may not do, enforce it on every developer’s machine, and keep a record your auditors can use.

How rules work

Each rule alerts or blocks.
Blocking happens on the developer’s machine, before the action runs.
Rules reach every machine at the start of each session and on every prompt.
Preview a rule against your team’s recent activity before you save it.
If SightLine can’t be reached, machines keep their last rules and never block by mistake.

Blocked by SightLine policy: .env.production is a protected path.

Blocking is enforced in Claude Code and Codex.

Deny a command
Alert or block
Any shell command containing the text, case-insensitive.
rm -rfgit push --forceterraform destroy
Protect files or folders
Alert or block
Gitignore-style patterns: a path with / is anchored at the repo root, a bare name matches anywhere, ~/ is the home folder.
.env**.peminfra/prod/**~/.aws/**~/.ssh/**
Allow only approved MCP servers
Alert or block
An allowlist of server names; anything else alerts or blocks. With no allow rules, every server is permitted.
githublinearsentry
Secrets sent to the model
Block typed prompts; alert on tool output
Anthropic, OpenAI, GitHub, GitLab, AWS, Google, Slack and Stripe keys, JWTs and private keys.
Personal data sent to the model
Alert only
Card numbers, US Social Security numbers and IBANs.

Alerts name the kind of data, never the value. Each rule has a severity and appears on the Alerts page.

Rule	Pattern	Action
Protect files or folders	.env*	Block
Protect files or folders	*.pem	Block
Protect files or folders	~/.ssh/**	Block
Protect files or folders	~/.aws/**	Block
Deny a command	git push --force	Block
Deny a command	rm -rf	Alert
Allow only approved MCP servers	Your approved list	Alert
Secrets sent to the model	(all kinds)	Block
Personal data sent to the model	(all kinds)	Alert

SightLine records what auditors ask about when AI agents touch production code: who changed what, who saw what, and which controls were in force.

Control area	What SightLine records	Where to get it
Change management (SOC 2 CC8; ISO 27001 change management)	Which agent changed which files, every commit’s line-level authorship, and each rule change with before and after values	Commits and edits export; rule-change export
Logical access (SOC 2 CC6; ISO 27001 access control)	Admin and developer roles, sign-in through your SSO, and every view of someone else’s stored content with who, whose and when	Access log page and export
System monitoring (SOC 2 CC7; ISO 27001 monitoring)	Blocked actions, alerts with first and last seen and resolution, secret and personal-data detection, prompt-injection flags on tool results	Alerts page and export
Policy in force	Whether each machine’s rules are current, the rules version, and the team setup’s version history	Alerts page (rules health), Setup history

SightLine isn’t itself SOC 2 or ISO 27001 certified. It produces evidence for your audit. Your auditor decides how it maps to your controls.

Exports are CSV or JSON, contain no prompts or code, and are available to admins behind your SSO.