Choose one task with a clear stop condition

Define an agent that can answer questions from a small approved equipment FAQ and, optionally, look up the status of a fictitious service ticket. A successful result cites the correct FAQ version or returns the known ticket state. The agent must never update a real ticket, send a message or change an account. Write the starting dataset, permitted identities, response contract and forbidden operations before touching the agent builder. An outcome is only complete when the system’s observed data matches the request.

Use one normal case, one missing-information case and one conflict case. The normal case should have a unique current FAQ passage; the missing case should require abstention; the conflict case should show an expired procedure and its approved replacement. If the agent quotes the expired version without explaining its status, it fails even though the quotation may be accurate. This is a useful fundamentals experiment because it exposes the boundary between model fluency and governed source evidence.

Give the fictional FAQ two near-identical questions, one asking for a routine login reset and another involving a locked administrator account. A model may confidently apply the routine procedure to both. The accepted output for the administrator case must preserve its escalation requirement rather than inventing a direct reset. Name the intended information source and who may approve a higher-risk step. The exercise connects a simple agent’s answer to the real safety meaning of the source material.

Select the supported agent capability

Microsoft Foundry Agent Service documentation describes managed agents and supported tools with capability and maturity differences. Verify which prompt-agent or hosted-agent features actually exist for your resource, model, region and API version. A working portal walkthrough from another tenant does not prove availability everywhere. Write down the selected agent type and endpoint before using an SDK example; agent definition and model deployment should be recorded separately.

For a beginner learning path, prefer a simple prompt agent rather than constructing a large multi-agent workflow. Configure a short system instruction defining the allowed user task, prohibited decisions and how to cite sources. Keep user text and uploaded documents as data. The agent instruction can request careful behavior, but cannot by itself enforce which business records a tool may read or change. That enforcement belongs to the real service and the application authorization layer.

Prepare a tiny authorized knowledge source

Choose three harmless troubleshooting notes: one active, one withdrawn, and one written for a different fictional customer. Attach stable document IDs, effective dates and an access-scope attribute. If the selected tool supports grounded search, verify that only current permitted documents become eligible for retrieval. A source that ranks highly by semantic similarity is not automatically current or authorized, and a prompt saying “ignore the restricted one” cannot undo content disclosure after the text has reached the model.

Test two fictional callers against the same question and log which source IDs were retrieved. An expected no-result or refusal is successful when the user lacks access or the evidence is absent. Record when the index was last populated and how withdrawn source content would be removed. This provides a realistic introduction to retrieval behavior without treating AI-901 as an advanced Azure AI Search tuning qualification.

Try revoking one fictional user’s access after the initial successful lookup. Query the same phrase again using the same model, index and user interface. If the restricted note still appears, investigate access filters or stale caches rather than trying to teach the language model to forget the contents. This demonstrates that permission changes are a data-system responsibility. Record the revocation time and the point when every retrieval path stops returning the document; avoid storing private text in a general trace export.

Define an exact, limited tool contract

If the agent needs a tool, start with a simulated read-only function such as fetch_ticket_status whose input schema accepts one approved ticket identifier. Its output should contain the canonical ticket ID, recorded state, source timestamp and explicit success or error status. Reject empty IDs, a different tenant, unexpected fields and requests to modify the ticket. A model-produced function name and JSON arguments are proposals; a trusted executor must check them before any invocation.

Provide two IDs with similar wording to see whether the agent guesses the target instead of asking. Include a test where the function returns “not found.” The final response must not claim the ticket is closed or verified without a tool result. If the runtime proposes a function outside the registry or changes the identifier, record a failed tool-choice case even if the final sentence looks helpful. Distinguishing proposed, authorized, executed and confirmed actions is a central engineering lesson.

Include a test in which the agent proposes fetch_ticket_status with two conflicting ticket IDs, one in the user request and one in a retrieved note. The application should use the authenticated request context and a verified target, not whichever string the model generated most recently. Require a second trusted check before executing a side-effecting operation. Even if the current teaching tool is read-only, identify precisely where business authorization would be enforced if the workflow were later extended to update_ticket.

Test direct and indirect prompt injection

An ordinary user may ask the agent to ignore restrictions and reveal another account’s ticket. A malicious note may embed the same instruction in material the agent retrieved for a legitimate question. Keep both as test cases, and label their trust levels. The desired defense is not merely an apologetic final sentence: the tool executor must refuse requests outside the acting user’s privileges. Retain a sanitized trace of attempted parameters and the authoritative denial.

Include a legitimate security-analysis question discussing attack instructions as data. A robust assistant should be able to summarize that document without following the commands inside it or refusing all discussion of prompt injection. This comparison distinguishes useful analysis from harmful obedience. At fundamentals level, the main concept is that retrieved text and tool results are lower-trust inputs; higher privileges come only from authenticated application rules, not from a model’s narrative.

Handle tool failure and ambiguous outcomes

Test a tool returning a temporary error and another returning an explicit authorization denial. Display these states truthfully. Bounded retries may be suitable for a read-only lookup, but a future action tool with external effects would need an idempotency key and a query of authoritative state after a timeout. An agent should not report a successful action merely because the model wrote one. This distinction becomes critical in more advanced workflows.

Apply a maximum number of iterations and a task deadline to prevent loops and runaway cost. Capture how many retrieval and tool calls occurred and whether the user received a useful or safe answer. If a tool’s output contract changes, treat that as a compatibility event rather than asking the prompt to infer new fields. A simple, tested tool registry with narrow permissions is better preparation than connecting every visible service without understanding its power.

Evaluate the path as well as the answer

Create a six-row evaluation sheet: permitted lookup, unknown ID, two similarly named tickets, restricted-tenant lookup, injected source text and temporary tool failure. For each row, record expected tool name, permitted arguments, authorized outcome and final response obligations. A final-answer score alone may miss an unauthorized tool proposal. Distinguish a tool suggestion that was rejected from an executed forbidden operation; the latter is a stronger failure.

Use deterministic checks for exact IDs, allowed tool names, role scope and transaction status. Use a simple rubric for readability and whether the answer explains uncertainty. Preserve the agent definition, model deployment, knowledge-source revisions, tool schema and evaluator version. If a model update produces smoother text but increases wrong-tool proposals, treat that as regression. This is sufficient to demonstrate an AI-901 agent lab without claiming a hidden model thought process was inspected.

In the negative test, the model may propose an unauthorized lookup while the mock executor correctly denies it. Record this as two observations: unsafe proposed arguments and successful containment by the application. If the final response truthfully says the lookup was refused, that is good communication but does not erase the attempted privilege boundary crossing. A useful evaluation sheet reports these separately. This makes it possible to compare safer model behavior with stronger downstream controls without conflating the two.

Document and remove the practice agent

Finish with a short runbook: project and model identifiers, agent type, tool registry, permitted identities, source versions, test results, known limitations and instructions to remove the test deployment. Verify the current resource and region guidance before describing the sample as repeatable. Delete stale permissions and unused tools rather than leaving a development agent able to access resources indefinitely.

Relate this exercise back to the AI-901 exam preparation map. The learner should be able to describe a prompt agent, configure one supported tool, inspect an actual tool result and explain why authorization happens outside model language. The purpose is controlled helpfulness, not a demonstration of maximum autonomy or a production-ready multi-agent architecture.