Safe and durable collaboration · chapter 11 of 17
Access, secrets, boundaries and responsibility
A tool gives an agent a technical capability, not automatic authority. Access should be minimal, secrets protected and external consequences clearly bounded.
11.1 · plain explanation
What may the agent read, change, publish or send, and who owns the decision?
A tool gives an agent a technical capability, not automatic authority. Access should be minimal, secrets protected and external consequences clearly bounded.
Important: A safety boundary is part of the product. It should not be removed merely because a technical shortcut is possible.
11.2 · building blocks
Three concepts to keep separate
Access
Grant only the file, system and network access the task actually needs.
Secret
Tokens, passwords and customer data must not be copied into logs, prompts or global memory.
Responsibility
The person owns business choices; the agent may own reversible technical choices inside the agreed scope.
11.3 · method
A practical workflow
- 1Classify the data and target before enabling tools.
- 2Choose the least permission necessary.
- 3Set stopping points for publication, messages and irreversible actions.
- 4Inspect logs and evidence for unintended exposure.
11.4 · concrete example
An SEO correction
An SEO correction
What may the agent read, change, publish or send, and who owns the decision?
The agent may change the agreed website and run tests.
It may not reuse that access to change a customer domain, rotate a production key or send messages unless that is part of the assignment.
11.5 · try it yourself
Exercise
Create a table with read, change, publish and send columns for one agent task. Fill in allowed, forbidden and requires a new decision.
11.6 · checklist
Before you continue
- Is least access selected?
- Are secrets absent from output and memory?
- Are customer and project boundaries preserved?
- Are external or irreversible actions separately controlled?
11.7 · sources
Sources
Reviewed 23 September 2026. Official sources support product-specific claims; the practical contract, memory and verification patterns are Finnandre project methods.