Govern agent behavior with oversight modes, constraints, and tool-access controls
AI-103 › Unit 1: Plan and manage an Azure AI solution › Implement responsible AI across generative AI and agentic systems › Govern agent behavior with oversight modes, constraints, and tool-access controls
Govern agent behavior with oversight modes, constraints, and tool-access controls
The previous objectives covered controls on content and controls on the record. This one covers controls on action — what an agent is permitted to do, on whose authority, and with how much human involvement. Governance here is layered: identity, tool surface, per-call approval, and network-level enforcement each stop a different failure.
Why This Matters
An agent acts. A chat model produces text and the worst case is a bad answer. An agent with tools writes to systems, moves money, and sends mail. The blast radius is set by the tools you attach, not by the model.
Instructions are not a security boundary. A system prompt is a strong behavioural signal and a weak control. Anything that must not happen has to be made impossible, not discouraged — by not attaching the tool, by scoping the identity, or by gating the call.
Oversight has settings, not just a switch. Full autonomy and approve-everything are the endpoints of a range. The examinable skill is placing a given scenario correctly along it.
Prerequisites
- What a tool is, and that agents choose tools autonomously at run time.
- Managed identity and Entra role assignment basics.
- That Foundry role assignments can be made at resource, project, or agent scope.
- The approval mechanism from the auditing objective.
Learning Objectives
By the end of this lesson you will be able to:
- Place a scenario on the oversight range from autonomous to approve-every-action.
- Constrain an agent's tool surface with a private catalog and version pinning.
- Apply identity scoping so an agent cannot reach what it should not.
- Use an AI gateway for rate limiting, IP restrictions, and centralised policy.
- Recognise where orchestration choice is itself a governance decision.
Building Blocks
Agent identity. Hosted agents run your code on platform compute and get a dedicated Entra identity per agent, so an agent's permissions are its own rather than the application's. That makes least privilege expressible at agent granularity: the refund agent and the reporting agent are different principals with different role assignments.
Role scope. Foundry role assignments apply at resource, project, or agent scope, with agent scope used for endpoint access. Two agents in one project can therefore have different reachable surfaces.
Tool surface. A private tool catalog limits which tools developers can attach at all — governance ahead of build time rather than review after it. A toolbox groups a curated set behind one MCP endpoint and is versioned (create → test → promote to default), so pinning a version freezes the tool surface an agent sees.
Structured inputs. Runtime overrides for file_search.vector_store_ids, code_interpreter.container, and mcp.server_label / server_url / headers let one agent definition be pointed at different data per caller. That is useful for tenant isolation and a governance concern in its own right, because it means the endpoint an MCP tool talks to can be set per request.
Per-call approval. require_approval pauses before invocation and resumes on approval — the pre-action control.
AI gateway. A gateway in front of model and agent endpoints centralises rate limiting, IP restrictions, authentication, and policy, so limits are enforced for every caller rather than depending on each application behaving.
Orchestration as governance. Sequential, concurrent, handoff, group chat, and Magentic differ in who decides what happens next. Group chat uses an orchestrator to decide which agent speaks; handoff transfers control directly between agents. Choosing an orchestrated pattern keeps a single decision point; choosing handoff distributes it.
The oversight range
| Attribute | |||
|---|---|---|---|
| Human involvement | Review after the fact | Before high-consequence calls | Before every call |
| Fits | Reversible, low-value, read-mostly | Mixed read and write surfaces | Irreversible or regulated actions |
| Failure mode | Damage before anyone notices | Miscategorising a tool | Rubber-stamping |
| Mechanism | Traces + evaluation |
| Approval on all tools |
Deep Dive
Constrain the surface before you gate the call
The strongest control is the one that removes an option rather than reviewing it.
If an agent has no delete tool, no approval workflow for deletion is needed and no prompt injection can provoke one. This is why the private tool catalog matters: it governs what can be attached at all, so the decision is made once by a platform team instead of repeatedly by every developer under delivery pressure.
Version pinning is the same idea across time. A toolbox is versioned, and promoting a new version to default is an explicit act. An agent pinned to a tested version does not silently acquire a capability because someone added a tool upstream — a real risk when tools are shared across teams.
Identity is the same idea across systems. A hosted agent's dedicated Entra identity means its reach is defined by its own role assignments; if it holds no write role on a data store, a tool that attempts a write fails at the platform, not at the prompt.
Layering the controls
Remove what should not exist
Do not attach the tool. Private tool catalog enforces this ahead of build time.
Where the oversight setting actually lands
Neither endpoint of the range is usually right.
Full autonomy is appropriate where actions are reversible, low-value, and read-mostly — a research agent that queries and summarises. Oversight there is retrospective: traces, evaluation, alerts.
Approve everything is appropriate where every action is irreversible or regulated, and rare in practice. Its failure mode is well documented: reviewers facing a stream of routine approvals stop reading, and the control becomes a click. The appearance of oversight is worse than none, because it is trusted.
Gating by consequence is the working default. Reads run freely; writes to systems of record, financial movement, outbound communication to third parties, and destructive operations pause for a human. The test to apply is what happens if this call is wrong — not how powerful is this tool.
The gateway layer
Application-level limits depend on every application implementing them. A gateway in front of model and agent endpoints does not.
It centralises rate limiting (protecting a shared quota from one misbehaving caller), IP restrictions (only approved networks reach the endpoint), authentication and key handling, and cross-cutting policy — logging, header injection, routing.
The discriminator in a question is usually the word every or all callers: "ensure no single application can exhaust the shared quota", "restrict access to corporate networks". Those are edge concerns. An SDK-level retry policy or a per-app configuration cannot enforce something for callers it does not control.
Injection is a governance problem, not only a filter problem
Indirect prompt injection is where content controls and action controls meet. The filter side is Prompt Shields for indirect attacks — GA, and off by default, so it must be enabled.
But the reason injection matters more for agents than for chat is that a successful injection does not merely produce bad text; it produces an action. The governance mitigations are the ones above: an agent that cannot reach the system has nothing to be redirected into, an approval gate puts a human between the injected instruction and the effect, and a scoped identity means a compromised tool call fails at the platform.
The general form: filters reduce the probability, constraints reduce the consequence. Questions that describe an agent ingesting third-party content and taking action are usually testing whether you reach for both.
Orchestration choice as a control
The multi-agent patterns differ in where the decision authority sits, which makes the choice a governance decision.
Group chat routes through an orchestrator that decides which agent speaks next — a single point where policy can be applied and observed. Handoff transfers control directly between agents, which is more fluid and leaves no central checkpoint. Magentic targets open-ended problems where the plan is not known in advance, so it needs the most instrumentation. Sequential and concurrent are the most constrained: the path is fixed at design time.
For a regulated flow, a fixed or orchestrated pattern with approval at the consequential step is easier to evidence than a free handoff network — and "easier to evidence" is usually the deciding factor when a scenario mentions audit or compliance.
Worked Examples
Example 1 — the agent that must never delete. A data agent queries and summarises a warehouse. Deletion must be impossible even under prompt injection.
Do not attach a tool that can delete, and scope the agent's Entra identity to read-only roles so a write attempt fails at the platform. A system-prompt instruction is the weakest option and is exactly what an injected instruction competes with. require_approval would be second-best — it puts a human in the path but still allows the call to be proposed.
Example 2 — one app exhausting shared quota. Several applications share a deployment; one occasionally exhausts the quota, and access must be limited to corporate networks.
An AI gateway in front of the endpoint: rate limiting per caller and IP restrictions, enforced for every caller regardless of what each application implements. Per-app retry configuration cannot enforce anything on an application that does not implement it.
Example 3 — a mixed-consequence agent. An agent reads order history, drafts customer email, and issues credits. Compliance requires human authorisation on financial actions and on outbound customer communication.
require_approval on the credit tool and the send-email tool, not on the read. Gating by consequence keeps the reviewer's attention where it matters; gating everything produces rubber-stamping on the two calls that actually needed reading.
Visual Explanations
The layered controls, and what each stops:
Injection: probability against consequence:
Common Mistakes
Choosing a prompt instruction over a structural control. Instructions shape, they do not prevent.
Gating every tool. Rubber-stamping; gate by consequence.
Treating the tool list as a development detail. It is the blast radius; a private catalog governs it.
Ignoring version drift in shared tools. Pin the toolbox version.
Assuming one identity for all agents. Hosted agents get a dedicated Entra identity; roles apply at resource, project, or agent scope.
Solving a cross-caller requirement inside one application. Rate limits and IP restrictions belong at the gateway.
Relying on filters alone against injection. Filters lower probability; constraints lower consequence — and the indirect shield is off by default.
Ignoring orchestration. Group chat centralises the decision; handoff distributes it.
Practice Exercises
- Rank these for making deletion impossible: system-prompt instruction,
require_approval, not attaching the tool, read-only identity scope. Justify the top two. - Which control enforces per-caller rate limits and IP restrictions across all applications, and why can this not be done per-app?
- Where does approval go on an agent that reads orders, sends email, and issues credits?
- How do a private tool catalog and toolbox version pinning differ in what they prevent?
- Why is orchestration choice a governance decision?
▶Answers
- Best: not attaching a delete tool and scoping the identity to read-only — both make the action impossible, one at the agent surface and one at the platform. Then
require_approval, which allows the call to be proposed but interposes a human. Weakest: the system-prompt instruction, which is exactly what an injected instruction competes with. - An AI gateway in front of the endpoint. It enforces for every caller; a per-application setting only binds applications that implement it, which is precisely the one misbehaving.
require_approvalon the credit tool and the send-email tool — financial action and outbound third-party communication. Not on the read: gating by consequence preserves reviewer attention where it counts.- The catalog constrains what can be attached at all, governing the surface ahead of build time. Version pinning constrains change over time, so an agent does not silently gain capability when a shared tool is added or altered upstream.
- Because the pattern decides where authority sits. Group chat routes through an orchestrator — one observable, policy-enforceable decision point. Handoff transfers control directly, leaving no central checkpoint. Fixed patterns are easiest to evidence, which usually decides regulated flows.
Summary & Concept Map
Agent governance is layered, and each layer stops a failure the others cannot. Identity decides what the agent can reach — hosted agents get a dedicated Entra identity, with roles assignable at resource, project, or agent scope. The tool surface decides what it can choose from — a private tool catalog governs attachment, and a pinned toolbox version stops capability drifting. require_approval interposes a human before consequential calls, gated by consequence rather than applied to everything, because blanket approval decays into rubber-stamping. An AI gateway enforces rate limits and IP restrictions for every caller. Against injection, filters lower probability — remembering the indirect shield is off by default — while these constraints lower consequence. And the orchestration pattern itself is a control: an orchestrator centralises the decision, handoff distributes it.
Sources and freshness
Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.