How to Scope an Agent's Data Access to a Policy Tier

A tier is only useful if it changes behavior. If your Confidential and Restricted tiers end up allowing the same tools with the same scopes, you have two labels and one policy. Force each tier to differ on at least three of these axes: read scope, write scope, external egress, and human approval.

Two rows deserve emphasis. The external send row is where most real damage happens, because copying information into a public tool breaks the boundary regardless of which tier the source data sat in. Policy templates for generative AI call this out repeatedly: state clearly that all company information is confidential regardless of format, and that copying, pasting, dictating, or uploading all count as violations the CRI employee AI use guidance. An agent makes the same mistake without anyone pressing a key, so the egress column has to be enforced by code.

The database row is where the most under-specified decisions live. "Read access to the customer table" is not a tier; it is an unbounded grant. Restricted-tier agents should read through a mediated index or a view with masking applied at query time, so the raw column never enters the model's context. This is the difference between a policy that survives an audit and one that survives only until the first prompt injection.

The temptation is to let an agent inherit the tier of whoever is chatting with it. Resist that for anything above Internal. An agent that inherits user tier at runtime has an effective tier equal to the most privileged person who ever types into it, and you will not be able to describe its permissions in a review. Context-aware enforcement that evaluates user role, data sensitivity, and intent alongside static rules is valuable, but it works best as a second layer on top of a fixed base tier, not as a replacement the Lasso guide to AI policy enforcement.

A workable assignment rule:

1. Start from the highest data class the agent must read to do its job at all. That sets the base tier.
2. If the agent writes, create tasks, or sends externally, confirm the write targets are at or below the base tier. Cross-tier writes require their own approval step.
3. If the agent must read Restricted data, split it into a read-only agent plus a human reviewer, rather than granting write scope to a Restricted agent.
4. Record the tier, the justification, and an owner in the same register you use for human role entitlements.

That register matters more than it sounds. Access reviews for agents fail the same way access reviews for people fail: nobody owns the entry, so nobody removes it. Playbooks that work for revenue systems apply here too, including inventorying where agents read or write today, whitelisting objects, fields, and verbs, and running scheduled recertification so dormant or excessive access gets removed the Pedowitz Group agent access playbook.

A tier that lives only in a system prompt is a suggestion. The model can be talked out of it, and retrieved content can carry instructions that redirect it. Enforcement belongs in the wrapper every tool call passes through, where the decision is deterministic and logged.

A minimal enforcement shape:

TIERS = {
  "public":    {"verbs": {"read"}, "egress": {"web"}, "approval": False},
  "internal":  {"verbs": {"read", "draft", "create_task"}, "egress": {"web", "approved_saas"}, "approval": False},
  "confidential": {"verbs": {"read", "draft", "write"}, "egress": {"approved_saas"}, "approval": True},
  "restricted": {"verbs": {"read_masked"}, "egress": set(), "approval": True},
}

def authorize(agent, tool, verb, data_class, destination):
    tier = TIERS[agent.tier]
    if verb not in tier["verbs"]:
        return deny("verb_not_in_tier")
    if rank(data_class) > rank(agent.tier):
        return deny("data_class_above_tier")
    if destination not in tier["egress"]:
        return deny("egress_blocked")
    if tier["approval"] and not agent.has_approval(scope=tool):
        return escalate("human_approval_required")
    return allow(record_decision=True)

Three properties make this worth writing. First, the check runs before the tool executes, so a blocked call never reaches the data. Second, denials are recorded with a reason code, which turns "why did the agent do that?" into a query. Third, the data class check is independent of the tool, which closes the chaining gap: a read scope in one system plus a write scope in another can produce a serious outcome even when each grant looked harmless alone the Pluto Security explanation of agent access control.

Runtime enforcement is also where regulators and auditors increasingly look. The expectation is shifting from documented safeguards at design time to evidence that controls are actively enforced during operation, including post-deployment monitoring and human oversight the Lasso guide to AI policy enforcement. A decision log with policy, verdict, and enforcement action per tool call is the artifact that demonstrates it.

Logging every decision is necessary but not sufficient. You also need to know what normal looks like for each tier, because an agent that starts reading outside its expected data classes is a signal whether or not a rule fired. Runtime monitoring for agent access usually tracks agent identity, session, delegated user context, tools invoked with arguments, data categories touched, and approval events the Pluto Security explanation of agent access control.

When a tier boundary is crossed, the response differs from a classic breach. An incident playbook for agent compromise treats unauthorized agent action as its own scenario, with indicators such as database queries or writes not in the agent spec and access to systems outside the permission boundary, and the containment step is to halt running processes and revoke permissions the Aona AI incident response playbook. Prepare that step in advance, because the fastest containment is a single flag on the agent identity.

The stakes are not hypothetical. A regional bank disclosed an incident stemming from an employee's use of an unauthorized AI application to process non-public customer information, with exposed data including names, Social Security numbers, and dates of birth, and it treated the matter as material under securities disclosure rules even though there was no operational disruption the Wilson Sonsini analysis of the disclosure. The lesson for agent scoping is that exposure alone can be material. A tier system that keeps Restricted data out of any agent without an approval gate is the cheapest version of that control you will ever buy.

A short pre-launch checklist for the tier, all answerable from the register and the decision logs:

• Every agent has a tier, an owner, and a one-line justification.
• No agent's egress set includes a destination outside the approved list.
• Restricted-tier agents hold no write verbs at all.
• Every Confidential write and every Restricted read produces an approval event.
• A single flag can disable the agent and revoke its credentials within minutes.
• The last recertification removed at least one stale grant.

If your team is standing up agents against several providers and wants one place to meter and separate traffic per tier, a unified endpoint layer helps; Quanta Inference (https://quantaintelligence.ai/inference) exposes text, image, video, audio, and embedding models through one OpenAI-compatible key, which makes per-tier routing and spend attribution a configuration detail rather than a separate integration per vendor.