Should security teams control agent access at the tool level or the field level?

Why the control boundary should follow the task, not the agent

The right control boundary is the smallest scope that still lets the agent complete the task safely. Tool-level access decides what the agent can do, but field-level control decides what it can see, retain, and accidentally propagate. If the task only needs a narrow answer, field-level restriction is the better default because it reduces unnecessary data exposure and shrinks the blast radius of a bad prompt, bad tool call, or bad downstream cache.

That distinction matters because many agent workflows fail at the read scope, not just at the action scope. An agent given broad tool access but unrestricted fields can still over-collect sensitive records, log unnecessary material, or carry privileged context into later steps. Least privilege only works when both the action and the payload are constrained to what the workflow actually requires.

How tool-level and field-level control differ in practice

Tool-level control is the coarse gate: it answers whether the agent may invoke a capability at all. Field-level control is the finer gate: it answers which attributes, rows, fragments, or values the agent may receive from that capability. A search tool, for example, may be appropriate, but the agent may only need a few returned fields rather than the full object. That is where field-level filtering is stronger than a binary allow or deny decision.

In practice, the safest design is to treat a tool call as two separate authorisation decisions. First, should the agent be allowed to perform this action? Second, if yes, what is the minimum readable or writable surface needed for that action? This is the same least-privilege principle applied to both execution and data visibility, and it is especially important when the agent can chain multiple tools or reuse context across steps. See AI Agent Authorisation Guide for a practical least-privilege model for per-action policy and task-scoped access.

When the agent is acting across multiple systems, the access decision also needs to track what identity or token is being used at each step. The boundary is not just “can the agent use the tool”, but “can this specific principal use this tool with this specific scope for this specific purpose”. That framing helps prevent overbroad delegation and makes it easier to review whether the same access would still be justified if the workflow changed. The Agentic AI Identity Guide is useful for understanding identity, delegation and retirement across the agent lifecycle.

Where field-level control becomes the better security pattern

Field-level control is most valuable when the agent only needs a small slice of a record, when sensitive attributes are mixed with ordinary operational data, or when the result may be cached, summarised, or reused in another context. In those cases, tool-level access alone is too blunt. The control should stop the agent from ever seeing the extra data in the first place, not rely on later filtering or model obedience. For a broader view of how this changes the agent attack surface, see Agentic AI Security Guide.

Field-level control also matters when the agent has high read volume but low decision complexity. In those workflows, the main risk is not that the agent performs a destructive action, but that it accumulates more context than the task justifies. Narrow payloads reduce accidental disclosure, lower retention risk, and make downstream redaction and logging simpler. That is the same reason many teams prefer selective disclosure in APIs and data-access layers rather than trusting every consumer to self-limit after the fact. For access-control failure modes that show up when enforcement is too coarse, the Broken Access Control Prevention Guide is a useful companion.

Practitioner Guidance

What to verify: Check whether the agent can complete the task with a reduced response shape, not just with a reduced tool set. If the answer is yes, default to field filtering first and expand only the specific fields needed for the next step.

Decision rule: If a field is not required to decide, act, or explain the result, do not return it to the agent. If the workflow genuinely needs broad record access, keep the tool but add explicit per-action approval, tighter logging, and stronger session boundaries.

What good looks like: The agent receives the minimum useful payload, performs the intended action, and cannot reconstruct sensitive context from surrounding fields, cached results, or repeated queries. That is stronger than “the tool is restricted” because it limits both misuse and unintended retention.

Practitioner takeaway: Tool-level control is necessary, but field-level control is what turns least privilege into a real reduction in exposure. When there is any meaningful choice, constrain the data surface as tightly as the action surface.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How can security teams tell whether agent access is actually under control?