The new problem is agent coordination, not just prompting
When one agent helps, the question is permission. When many agents work in parallel, the question becomes governance: who can read, who can write, who can call tools, who can open PRs, who can touch environments and who owns the result?
Antigravity, Managed Agents and Gemini CLI subagents make this pattern more common. The speed gain is obvious. So is the risk: independent tasks can touch the same security boundary without anyone noticing.
Practical rule per agent
- One small objective per agent.
- Tools allowed by task, not convenience.
- No production secret in context.
- No write access to real databases.
- Separate branch and reviewable PR.
- Tool-call logs without private payloads.
- Human approval before deploy, migration, payment and auth changes.
What to inspect in SaaS
Agents are often useful on UI, copy, tests and documentation. Risk grows when they touch server routes, webhooks, paid plans, tenants, storage, login, mobile and external integrations. A small middleware change can carry more risk than an entire screen.
If the app has real customers, use the Promptbook to separate signals by flow. When the signal touches revenue or data, Risk Review should decide priority without forcing a full pentest too early.
Warning signals
- An agent asks for broad permission because it "needs to test".
- A subagent reads env files, dumps, logs or artifacts.
- Two branches change auth, billing or schema at the same time.
- Deploy runs without login and checkout smoke tests.
- Visual tests pass while the API is broken.
Sources
The more agents you run, the more important it is to know who could do what, where and with what evidence.
