Should organisations treat agent instructions as part of the access control model?

Why agent instructions belong inside access control

Agent instructions are not just content, they are an execution input that can expand or redirect privilege. If an agent can follow untrusted instructions, then access decisions are being made partly by the content of those instructions, not only by the identity holding the session. That is why instruction trust, tool scope, and action scope need to sit inside the same control model.

For organisations, the practical question is whether an instruction can cause a tool call, data read, transaction, or delegation that the issuing party would not otherwise be allowed to perform. Where the answer is yes, the instruction channel becomes part of the authorisation surface and should be governed as such.

What changes when instructions can drive actions

The main shift is that privilege can be abused without stealing a password, token, or key. A low-trust instruction source can still induce a high-trust agent to act inside legitimate credentials, which means the security boundary is no longer only “who authenticated” but also “what instruction source is trusted to shape the agent’s decisions.”

This matters most when the agent can chain instructions into tool use, data access, or downstream delegation. The more autonomy an agent has, the more important it becomes to treat instruction provenance, approval state, and permitted tool set as access control inputs rather than informal guidance.

That is why agent governance should align the instruction source with the action it can trigger, then constrain the agent with the smallest viable permission set. NHIMG’s AI Agent Authorisation Guide frames this as task-scoped and just-in-time access, with per-action policy decisions and human approval where the action is sensitive.

How to govern instruction trust, tools, and action scope

The useful control question is not whether an instruction is “helpful”, it is whether the instruction source is authorised to influence a particular class of action. In practice, that means separating instruction intake from action execution, then evaluating the instruction source, tool permissions, and target resource before the agent acts.

• Authorize which instruction sources the agent may trust for operational decisions.
• Limit the tool set the agent can invoke for each task or environment.
• Bind higher-risk actions to approval, policy checks, or short-lived delegation.
• Review whether the agent can be induced to exceed the original user intent.

NHIMG’s Authorisation Models Guide is useful here because this problem is not only role based, it often needs attribute, relationship, or policy based decisions about source, context, and action.

NHIMG’s Identity Governance for AI Agents Guide also fits the lifecycle side of this question, especially where instruction trust is tied to agent ownership, reviews, offboarding, and entitlement drift.

Risk and Threat Considerations

When instruction sources are treated as out-of-band, attackers can abuse trusted agents as a privilege amplifier. The failure mode is instruction injection, prompt injection, or compromised upstream content steering an agent into actions that look legitimate because they were executed under valid agent credentials and within an apparently authorised workflow.

Failure mechanism: A malicious or untrusted instruction is accepted as operationally valid, then converted into tool calls, data exposure, or delegated actions that bypass the human’s intended scope.

Impact: The organisation can lose control over what the agent does with its legitimate access, which can produce data leakage, unsafe transactions, lateral movement, or misuse of trusted integrations without any credential theft.

Practitioner Guidance

What to verify: Check whether the agent can distinguish trusted operator instructions from user content, retrieved content, or external prompts before it decides to act. If it cannot, treat instruction trust as an access control gap, not a model quality issue.

Decision rule: If an instruction can trigger a material action, require the same governance you would require for any other privileged request: explicit source trust, bounded tool access, and a defined approval path for high-impact operations.

Practitioner takeaway: The safe default is to assume that any instruction capable of changing an agent’s behaviour is part of the authorisation surface until proven otherwise.

Related resources from NHI Mgmt Group

• When should organisations treat agent output integrations as part of access governance?
• Should organisations treat multimodal AI as part of their identity and access model?
• Which compliance frameworks require organisations to treat Active Directory security as part of broader access control and monitoring obligations?
• Should organisations treat third-party access, cloud entitlements, and data access as one control model?