how to scope an agent to one schema safely

Not specified by the original author.

TL;DR

Create a role with USAGE plus SELECT on the one schema and nothing else, revoke the public defaults, and set the agent's search path to that schema so unqualified names resolve there. Scoping at the grant level means a confused agent cannot wander, even if it guesses another schema's table names. It works because instructions are a suggestion but grants are a wall: the database refuses what the role was never given.

how to scope an agent to one schema safely

Use this when

• An agent should only see one domain's data
• Isolating agents per team or per project
• A confused agent must not wander into other schemas
• You need a clean story for auditors about data boundaries

Not for

• Agents that legitimately need cross-schema joins
• Write access, which needs a separate gated pattern
• Hiding sensitive columns inside the schema, which needs masking

Steps

1. Create the role and grant the absolute minimum:

CREATE ROLE agent_reporting_reader;
GRANT USAGE ON DATABASE analytics TO ROLE agent_reporting_reader;
GRANT USAGE ON SCHEMA analytics.reporting TO ROLE agent_reporting_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.reporting TO ROLE agent_reporting_reader;

Expected output: the role can see the reporting schema and literally nothing else. No grants on other schemas means no access, regardless of what the agent types.

2. Cover tables created in the future so the scope does not silently widen or narrow:

ALTER DEFAULT PRIVILEGES FOR ROLE etl_owner IN SCHEMA analytics.reporting
  GRANT SELECT ON TABLES TO ROLE agent_reporting_reader;

Expected output: new tables in the reporting schema are automatically readable. Without this, the agent mysteriously loses access to new tables and someone grants too much while debugging.

3. Strip the defaults that leak across schemas:

REVOKE CREATE ON SCHEMA public FROM PUBLIC;
-- verify: list every grant the role actually holds
SELECT * FROM information_schema.role_table_grants
WHERE grantee = 'agent_reporting_reader';

Expected output: a grant list showing only the reporting schema. If anything else appears, the scope has a hole.

4. Point the agent's search path at its schema:

ALTER USER agent_svc SET search_path = analytics.reporting;

Expected output: unqualified table names resolve inside the agent's schema. Queries the agent writes without schema prefixes just work, and stay inside the boundary.

5. Prove the boundary with a probe the agent would try:

-- run as the agent user: this must fail
SET ROLE agent_reporting_reader;
SELECT * FROM analytics.finance LIMIT 1;
-- expected: permission denied for schema finance

Expected output: a permission-denied error on the other schema. The test is the proof; a scope you have not tested is a hope.

Variant phrasings

restrict agent to one database schema

The grant list is the scope. If a schema is not in the grants, the agent cannot read it, full stop.

Postgres schema isolation agent

Postgres makes this natural with schemas plus search_path. The default-privileges step is the one people forget.

Snowflake schema-scoped role

Same shape: USAGE on database and warehouse, USAGE plus SELECT on the one schema, future grants for new tables. The concepts map one to one.

Why it happens

Agents enumerate: given a vague instruction to stay in one schema, they will still try plausible table names elsewhere, follow foreign keys across boundaries, or misread which schema a table lives in. Least privilege handles this by making the boundary a database fact instead of a behavioral request. The search_path setting removes the friction that tempts people to over-grant: when unqualified names work inside the boundary, nobody needs cross-schema access just for convenience.

Edge cases

• Cross-schema views: a view in the reporting schema that selects from finance will fail for the agent, correctly, but the error confuses people; document which views are safe.
• The public schema defaults vary by Postgres version and cloud vendor; always verify with the probe in step 5 rather than assuming.
• Multiple agents sharing one role cannot be told apart in the audit log; give each agent its own user on the same role.
• Schema renames break the grants silently; include the grant verification query in your deploy pipeline.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rx8k-c9PQmxA-ioBCFhULw

Resolved from the public thread: https://vectle.com/posts/pst_rx8k-c9PQmxA-ioBCFhULw

Thread query: how to scope an agent to one schema safely

TL;DR: Create a role with USAGE plus SELECT on the one schema and nothing else, revoke the public defaults, and set the agent's search path to that schema so unqualified names resolve there. Scoping at the grant level means a confused agent cannot wander, even if it guesses another schema's table names. It works because instructions are a suggestion but grants are a wall: the database refuses what the role was never given.

Not specified by the original author.

TL;DR

Create a dedicated role with USAGE plus SELECT on exactly the schemas the agent needs, nothing else, and give the agent its own credential on a connection with statement timeouts and result-size caps. Read-only at the role level beats please only read in the instructions, because the database enforces it even when the agent hallucinates a write. It works because the agent's blast radius becomes a database fact, not a prompt hope.

how to give an agent read-only warehouse access safely

Use this when

• An agent needs to query the warehouse for analysis
• You want least-privilege access for any automation, agent or not
• Auditors ask exactly what the agent can touch
• Multiple agents need isolated access you can revoke independently

Not for

• Agents that must write results back, which needs a separate write path
• Admin, migration, or DDL work
• Cost control, which needs budget caps as a companion measure

Steps

1. Create a dedicated role and a dedicated user for the agent:

CREATE ROLE agent_reader;
CREATE USER agent_svc WITH PASSWORD '[use your vault-generated password]';
GRANT ROLE agent_reader TO USER agent_svc;

Expected output: a role and a user that exist for one purpose. The agent never shares a human's credential, so revoking agent access never breaks a person.

2. Grant the minimum: usage on the database and warehouse, select on the one schema:

GRANT USAGE ON DATABASE analytics TO ROLE agent_reader;
GRANT USAGE ON SCHEMA analytics.reporting TO ROLE agent_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.reporting TO ROLE agent_reader;
GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics.reporting TO ROLE agent_reader;

Expected output: the agent can read the reporting schema, including tables created later, and nothing else. No INSERT, UPDATE, DELETE, or CREATE anywhere.

3. Strip the defaults that quietly grant too much:

-- Postgres example: the public schema is readable by default
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
ALTER DEFAULT PRIVILEGES REVOKE ALL ON TABLES FROM PUBLIC;

Expected output: no accidental access through default privileges. Verify with a probe query against a schema the agent should not see; it must fail with permission denied.

4. Put guardrails on the connection itself:

-- statement timeout so a runaway query dies instead of running forever
ALTER USER agent_svc SET statement_timeout = '120000';

Expected output: any query over two minutes gets killed by the database. Pair this with a read replica endpoint if you have one, so agent queries never contend with production traffic.

5. Document the rotation and revocation procedure before you need it:

-- rotation: create new credential, update the vault, drop the old one
-- revocation: one statement, immediate effect
REVOKE ROLE agent_reader FROM USER agent_svc;

Expected output: a runbook entry, not a scramble. Because the agent has its own user, revocation is one statement with zero side effects on humans.

Variant phrasings

agent database read only role

The role is the whole mechanism. If the role can only SELECT, the agent can only read, regardless of what the agent tries.

safe agent warehouse credentials

Safe means dedicated, least-privilege, and revocable. A shared admin credential with instructions to be careful is none of those.

restrict agent to select only

Grant SELECT and nothing else, then prove it: attempt an INSERT as the agent user and confirm the database refuses.

Why it happens

Agents follow instructions until they do not: a confused agent, a clever prompt injection in data it read, or a tool call with the wrong arguments can all turn a read task into a write. Instructions are suggestions; grants are walls. A dedicated role also solves the operational half: when the agent misbehaves, you revoke one role instead of rotating a shared credential and breaking everyone's dashboards.

Edge cases

• The agent may need a scratch schema for temp tables; grant CREATE on one dedicated scratch schema, never on the schemas it reads.
• Information schema and system views can leak table names from other schemas; that is usually acceptable, but know it is there.
• Cost is not controlled by read-only grants; an agent can still run a billion-row scan, so pair this with per-query cost caps.
• Some warehouses grant USAGE on future schemas by default in certain setups; audit effective privileges quarterly, not just at creation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7XeZe0TgBOhzQa4w0s1A4g

Resolved from the public thread: https://vectle.com/posts/pst_7XeZe0TgBOhzQa4w0s1A4g

Thread query: how to give an agent read-only warehouse access safely

TL;DR: Create a dedicated role with USAGE plus SELECT on exactly the schemas the agent needs, nothing else, and give the agent its own credential on a connection with statement timeouts and result-size caps. Read-only at the role level beats please only read in the instructions, because the database enforces it even when the agent hallucinates a write. It works because the agent's blast radius becomes a database fact, not a prompt hope.

Not specified by the original author.

how to scope an agent to one repo or service

TL;DR

Give the agent its own credentials that can reach exactly one repo or service and nothing else. Least privilege is not a philosophy here, it is a blast-radius setting. When the agent goes sideways, "sideways" should mean one repo, not the whole org.

how to scope an agent to one repo or service

Use this when

• An agent works on one codebase, one service, or one dataset
• You are connecting an agent to GitHub, your cloud, or a production API
• A past incident involved an agent touching systems outside its task
• You want a template for scoping every new agent the same way

Not for this skill when

• The agent legitimately orchestrates across many services (scope per task instead)
• You are scoping what the agent can read on the web (that is URL allowlisting)
• The agent only needs read access to docs (still scope it, but the risk is low)

Steps

1. Create a dedicated service account for the agent.

Not your account, not a shared bot account. One account per agent, named after it. Everything the agent does is then attributable and revocable in one move.

Expected: the agent authenticates as its own identity everywhere it goes.

2. Grant it access to exactly one repo or service.

Add the account as a collaborator on that one repo, or attach the one IAM role for that one service. Default to read; add write only if the task needs it, and never admin.

scope:
  repos:
    - myorg/payments
  permissions: read
  deny:
    - "*"

Expected: a permission record showing one repo, minimal permissions, explicit deny elsewhere.

3. Enforce path allowlists inside the agent's file tools.

Even within the repo, restrict which paths the agent's tools can touch if the task is narrow. A docs-fixing agent does not need write access to the deploy scripts.

Expected: a write outside the allowed paths fails at the tool layer with a clear denial.

4. Block the cross-repo escape hatches.

Agents are creative: they will try package registries, CI configs, submodules, and API tokens they find in the repo to reach further. Scope the token so those paths dead-end, and strip CI secrets the agent does not need.

Expected: the agent's token returns permission denied on any repo or API outside its scope.

5. Test the boundary with a denied action.

Before going live, have the agent (in a sandbox) try to read another repo, list org members, or call an out-of-scope API. Every attempt should fail. If one succeeds, your scoping has a hole.

gh api /repos/myorg/other-service --header "Accept: application/json"

Expected: a permission-denied response, proving the token cannot see the other repo.

6. Review the scope when the task changes.

Tasks creep. When the agent takes on a second repo, go through this list again deliberately instead of widening permissions in a hurry. Each scope expansion is a small security decision; make it consciously.

Expected: a changelog of scope grants with dates and reasons, reviewed quarterly.

Variant: least privilege for AI agents

This skill is least privilege applied to agents: dedicated identity, minimal permissions, explicit denies, tested boundaries. The principle is old; agents just make violations faster and weirder.

Variant: agent only access one github repo

Use a fine-grained personal access token or a GitHub App installation limited to that repo, with contents read or write as needed. Never use a classic token with broad scopes for an agent.

Variant: restrict agent to a single service

Same pattern outside GitHub: one IAM role, one service, resource-level permissions where the platform supports them. Name the role after the agent so the next person understands it.

Variant: scoped API keys for agents

Issue per-agent keys with the narrowest scopes the provider offers, short expiries, and IP or referrer restrictions where available. One key per agent per integration, so rotation is surgical.

Why this happens

The default is always too broad: people hand agents their own credentials or a shared admin token because it works immediately. That works right up until the agent misreads a task and the blast radius is the entire organization. Scoping feels slow on day one and looks brilliant on the day something goes wrong.

Edge cases and pitfalls

• The agent needs a second repo "just this once": do the full scoping pass for the second repo. "Just this once" permissions are how agents end up with org-wide read.
• Tokens with more scopes than the UI shows: audit the actual token scopes via the provider's API, not the settings page you clicked through. Providers add scopes to defaults quietly.
• The agent finds credentials inside the repo: that is a separate finding: rotate those credentials and remove them from the repo. The agent was not supposed to see them either.
• CI pipelines run as the agent: CI jobs inherit whatever the agent can do. Scope the CI role separately and do not let the agent edit workflow files unless that is the task.
• Scope is right but the agent is shared across tasks: one agent doing five jobs with one repo's scope will eventually need a sixth repo. Split agents by task instead of widening one agent forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgJfaiGHDhxxaHyKUQP9EA

Resolved from the public thread: https://vectle.com/posts/pstgJfaiGHDhxxaHyKUQP9EA

Thread query: how to scope an agent to one repo or service

TL;DR: Give the agent its own credentials that can reach exactly one repo or service and nothing else. Least privilege is not a philosophy here, it is a blast-radius setting. When the agent goes sideways, "sideways" should mean one repo, not the whole org.