January 25, 2026 • Márton Sereg, CEO & Co-Founder
The failure mode on one side is giving agents too much permission and hoping nothing goes wrong. The failure mode on the other side is scoping permissions so tightly that agents fail on legitimate tasks and teams disable the controls entirely. Both outcomes leave you worse off than if you had done nothing. The goal is permissions narrow enough to contain a compromise and broad enough to let the agent actually work.
Most teams start by listing what tools an agent can use and granting access to all of them. The better approach is to start from what the agent must do to complete its job, and grant only what that requires.
Write the job description as a set of sentences: "This agent reads customer records from the CRM. It queries the knowledge base for relevant articles. It writes a response draft to the ticketing system. It does nothing else." Each sentence maps directly to a permission: CRM read, knowledge-base read, ticketing-system write. Everything that is not in the job description is denied by default.
The common objection is "but we're not sure what tools the agent might need." That uncertainty is a design problem, not a permission problem. If you cannot write the job description for an agent, you have not finished designing it. Deploy to a test environment first, capture all tool calls in audit logs, and use the observed call patterns to write the policy. Do not grant broad permissions because you have not yet done the design work.
The most granular scoping specifies exact API endpoints and HTTP methods, not just service names. A CRM permission should specify:
GET /customers/{id} — permittedGET /customers (list endpoint) — denied (bulk enumeration risk)PUT /customers/{id} — denied (read-only agent)DELETE /customers/{id} — deniedIf your identity layer cannot enforce at the endpoint-and-method level, you can achieve a similar effect by deploying the agent behind a purpose-specific API facade that only exposes the permitted operations and rejects everything else. The facade is simpler to implement than a full identity layer and provides meaningful containment.
Resource scoping tells the agent which systems it can reach. Data scoping constrains what it can see within those systems. A support agent should read only the records for the customer session it is handling, not all customer records. This requires the identity layer to pass the session context as a policy input.
In OPA policy terms: "Agent A may read customer records where customer_id = {session.customer_id}." The session context is injected at identity issuance time and is part of the signed certificate. The agent cannot manipulate it because the certificate is cryptographically bound to the issuer, not the agent.
Even well-scoped permissions can be abused if the agent makes abnormally many calls. A rate limit per agent identity catches bulk data access even when each individual call is within the permitted scope. For a support agent, a limit of 50 CRM reads per session lifetime is generous enough to handle legitimate use and tight enough to make bulk enumeration impossible within the session window.
Some agents genuinely need broad access. An analytics agent may need to read across all customer records. A data migration agent may need read-write access to multiple systems. The principle here is not "never grant broad access" but "grant broad access only to agents that are designed for it, deployed in isolated environments, and subject to the highest audit scrutiny."
A broad-access agent should be deployed in its own namespace, logged at full verbosity, and subject to human review of its audit trail on a regular cadence. The combination of containment (isolated environment) and visibility (full audit) provides a different kind of security than narrow permissions do, but it requires operational investment. Most teams are better off keeping the majority of their agents narrow and creating dedicated high-privilege environments for the few workloads that genuinely need them.
Márton Sereg is CEO & Co-Founder of Riptides. Questions: hello@riptidesio.com