# CyberBrain Agent Guard — product brief V5 **Status:** recommended commercial hypothesis after desk research; customer validation is still pending **Product family:** CyberBrain26 **Initial delivery:** locally installed Linux command-line product; one supported host configuration and one agent/tool integration. ## One-sentence description CyberBrain Agent Guard helps a software team control how its existing AI coding agents act on private repositories, with explicit local authorization and a reviewable record of decisions and changes. ## Intended first buyer and user **Buyer hypothesis:** a CTO, engineering lead, or security/platform lead at a software team with roughly 10–100 developers that already uses AI coding agents and needs more control over shell/code execution and project changes. **Primary user:** a developer running an existing agent against a private repository. The first paid offer should be a guided, team-sponsored pilot; execution remains local on the supported developer workstation. This segment and problem are unvalidated assumptions, not an approved market decision. Use [CUSTOMER_DISCOVERY_V5.md](CUSTOMER_DISCOVERY_V5.md) to verify the buyer, budget, pilot workflow, supported agent, operating system, and policy defaults before expanding development. The potential market is global; the initial discovery sample should include both Czech and international users rather than treating the Czech Republic as the product's boundary. Aim for the first paid pilot wherever a qualified buyer has the clearest recent problem and can run the supported Linux workflow. If V5 keeps a global market, the install guide, CLI help, and pilot materials need clear English; Czech support can make the first local pilots easier. ## Problem to validate When coding agents can execute commands or modify a repository, a team lead may not know exactly what will run, what access it has, what files it will change, or whether project data will be sent to a remote model. Existing controls may be split across tools or available only inside one vendor's agent. The paid problem must be an actual gap in the customer's current controls, not a general preference for more security. Do not present this as proven demand until people describe recent examples and agree to test or pay for the proposed workflow. ## Proposed MVP workflow 1. The user selects a project and gives one supported agent a task. 2. The agent requests a concrete action, such as running Python or shell in a bounded workspace. 3. CyberBrain evaluates identity and policy outside the model, then shows the exact action, scope, workspace, and any relevant network/model-data disclosure. 4. The user approves or denies when policy requires it. Any denial, timeout, unavailable approval path, or sandbox failure blocks execution. 5. The action runs in the supported sandbox backend without a host-process fallback. 6. The user reviews the output and project diff, then chooses whether to bring changes into the main working tree. 7. A local, persistent history records the task, authorization decision, reviewer, execution result, and failure reason. ## Product boundaries for the first pilot - Single user, local installation, Linux only; choose the exact distribution/version from customer evidence and CI support. - One agent/tool integration, selected after interviews. Do not build a general agent framework or coding model. - Python/shell execution only if the threat review accepts the supported host and workspace boundary. - Local SQLite state and audit, with explicit backup and retention guidance. - Local model or explicitly selected remote provider. Never silently route local work to a cloud provider. - No central team administration, SSO, web portal, browser/GUI automation, compliance certification, or hostile-code guarantee. ## What customers should be able to buy first A guided, team-sponsored paid pilot on a supported Linux workflow, including installation, one agreed coding-agent integration, onboarding, and measured results. Test scoped pilot prices before publishing a list price; the proposed ranges and annual team-license model are hypotheses in [market and monetization analysis](MARKET_AND_MONETIZATION_ANALYSIS_V5.md), not approved prices. Do not sell an enterprise subscription until the product includes the requested team controls and security evidence. ## Proof required before a broader launch - A new user can install and complete the demo without the author operating the tool for them. - The user can accurately describe the action they approved and identify the files changed. - No known policy bypass or insecure fallback exists in the supported product path. - Model data egress, local storage, retention, supported hosts, and sandbox limitations are disclosed. - At least one customer has paid for a pilot and another has completed a pilot or committed to a defined purchase. ## Competitive position to test Coding platforms increasingly bundle their own approvals, sandbox, administration, and audit. CyberBrain's potential wedge is an independent local control layer across selected existing agents, with transparent model egress and reviewable changes. This has to prove a material gap beyond a customer's current agent controls; otherwise productize a paid integration service or change the segment. The full competitor review and monetization proposal are in [market and monetization analysis](MARKET_AND_MONETIZATION_ANALYSIS_V5.md). See the sourced comparison and scope decisions in [ROADMAP_V5.md](../../ROADMAP_V5.md).