Alpha validation brief
We are testing the approval-record pain, not pretending the platform is finished.
Scout is a strong hypothesis: teams approving AI coding agents need repo-local evidence that explains what agents can read, execute, or change. The alpha exists to prove or disprove that with real repository runs.
The hypothesis
Approval without repo-local evidence is becoming the gap.
Security teams already know how to review code, dependencies, secrets, and infrastructure. What is newer is the agent layer: local tool access, MCP config, inherited instructions, and repository-specific behavior that may authorize reading, execution, or changes before anyone has written a new line of code.
Validation questions
Five questions decide whether Scout deserves more product.
When developers use AI coding tools, do reviewers know what those tools can access in a repo?
Are MCP servers or repo-level agent instruction files reviewed by security today?
Would a local report on READ / EXECUTE / CHANGE authority be useful, or do existing controls already cover it?
How are agent approval decisions documented today?
Would you run Scout on one real repo and tell us what did or did not help?
Real-run protocol
One command, one repo, one useful answer.
Install
go install github.com/Orisan-org/orisan-scout/cmd/orisan@v0.1.0-alpha.4
Run
orisan scout
Review
Open orisan-scout-review.md and orisan-scout-review.json.
Reply
Share run success, finding count, usefulness, noisy findings, and missing coverage.
Testers should not share source code, secrets, prompts, or private reports unless their policy explicitly allows it. Finding count, usefulness, noise, and missed coverage are enough.
Signals
Success looks like pull.
Failure is useful too.
Alpha path