Decide what your agent can change
Artur Sabirov2 min readRevised September 7, 2026. Product details reflect this revision.
An instruction such as “inspect the database, but do not change it” describes what you want an agent to do. It does not change what the database will accept from the credential you supplied.
If that credential can write, a write request may still succeed. This is why choosing access belongs before starting the task, alongside choosing the instructions.
Turn the task into a permission decision
Consider a hypothetical investigation into missing orders. The agent needs to read relevant records and explain what it finds. It does not need to delete records to answer that question.
A read-only credential gives the service a way to refuse writes even if the agent attempts one. The same reasoning applies to deployment or access management: identify the operations the task needs, then choose permissions that permit those operations.
Many services offer limited credentials or roles. The difficulty for a team using several services is applying that decision consistently. A narrow database credential does not make a broad deployment credential safer. Each credential needs its own check.
Keep the limits understandable
A restriction helps only if you know what it covers. “Read-only” may still allow reading sensitive information. A product grant may include several services. A credential's display name may say “staging” without enforcing any environment boundary.
In Lessly, roles describe allowed and denied operations. Product access and permissions are checked by the platform. Grants are scoped to products; they are not a way to restrict access to a preview environment alone.
Credential type matters too. A personal API key uses its creator's identity and can reach other products that person belongs to when the request selects them. Do not treat the key's default product as a security boundary. Read the API-key behavior before using one for an agent.
Plan how the access will end
For temporary work, use an expiry where the access mechanism supports one. Otherwise, make removal part of finishing the task. Keep enough information to find the grant or key again: its identity, purpose, and owner.
Removing one grant ends the access that grant provides. It does not erase data already read, undo earlier changes, or necessarily remove access provided another way. In Lessly, for example, removing an explicit product share does not remove access inherited through an owner or admin organization role.
The product-access guide explains those cases. They matter most when you are checking whether a person or agent has actually lost access, rather than whether one removal request succeeded.
Review the setup before the work starts
For the missing-orders investigation, ask two concrete questions: can the credential read what the investigation needs, and can it change anything it should only inspect?
Then apply the same check to every service the agent will use. Good instructions guide the work. Permissions give the services a separate way to enforce its limits.
Related posts
Building Lessly in the open
Follow along, and get early access to the private beta.