Wire Action-Enabled Agents with Least Privilege

Tier: Advanced · Workflow area: Assistants & RAG · ~45 minutes

This playbook takes a working Q&A bot and adds its first actions using Freshservice Freddy AI Agent Studio, Atlassian Rovo agents, or a custom agent calling Microsoft Graph API through an MCP-style tool layer. The engineering is the easy half; the discipline — least privilege, risk classes, logs — is what makes it survivable, and it is what UC-44 actually asks of you.

When to use

• The bot answers well but users still wait for handspassword resets, group membership, license checks and ticket creation are your top repeat actions and each has a documented manual procedure.
• You can mint a scoped service identityyour tenant lets you create an app registration or service account with narrow, auditable permissions. Least privilege is possible, so it is mandatory.
• The auto-resolve matrix exists or is in flightactions ship against a signed policy (pb-43). If leadership has agreed what the agent may touch, this playbook is the implementation.

When NOT to use

• On a shared admin credentialif the only way to grant the bot access is a human admin's account or a tenant-wide role, stop. An over-privileged agent is a breach with good intentions.
• For irreversible or high-blast-radius actionsdeleting accounts, wiping devices, changing MFA methods, touching executive or admin identities. These stay human, whatever the platform demo showed.
• Before escalation worksan agent that acts but cannot hand off cleanly (pb-40) will act instead of escalating. Wire the exits first.

The recipe

1. 1.

   Classify every candidate action by risk before writing any config. Three classes, one table you will reuse in pb-43:

   Class	Meaning	Examples	Gate
   R1 read	No state change	license lookup, ticket status, group listing	Auto
   R2 reversible write	Undo exists and is documented	create ticket, add comment, standard-group add	Auto + log
   R3 sensitive write	Affects auth or access	password reset, MFA-adjacent, software grant	Human approval

   Anything you cannot place is R3 by default.

2. 2.

   Mint the agent its own identity, scoped to the table. For a Graph-backed agent, create a dedicated app registration and grant only what R1/R2 require — for example User.Read.All and Group.ReadWrite.All scoped by administrative unit, never Directory.ReadWrite.All. Verify the grant from the CLI, not the portal memory:

   Copy

   # List what the app registration can actually do
   az ad app permission list --id "$APP_ID" -o table
   
   # Password-reset rights come from a scoped role assignment,
   # not an app permission — restrict it to an administrative unit:
   az rest --method POST \
     --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments" \
     --body '{"roleDefinitionId":"<helpdesk-admin-role-id>",
              "principalId":"<agent-sp-object-id>",
              "directoryScopeId":"/administrativeUnits/<standard-users-au-id>"}'
   

   The administrative-unit scope is the difference between "the bot can reset standard-user passwords" and "the bot can reset the CFO's password."

3. 3.

   Define each tool narrowly — verbs, not surfaces. Whether it is an MCP tool, a Freddy Agent Studio action, or a Rovo agent action, the tool contract is one verb with typed inputs:

   Copy

   {
     "name": "reset_user_password",
     "description": "Reset password for a STANDARD user after identity verification. Never for admin, executive, or service accounts.",
     "input": {"user_upn": "string", "ticket_id": "string"},
     "risk_class": "R3",
     "requires_approval": true
   }
   

   A ticket_id input on every write action is deliberate: no action without a ticket to hang the audit trail on.

4. 4.

   Enforce R3 approval outside the model. The approval gate is code or platform config — a Studio approval step, a Rovo human-in-the-loop checkpoint, or your own queue — never a prompt instruction. A prompt that says "ask before resetting" is a suggestion; a tool layer that refuses to execute requires_approval actions without a signed approval token is a control.

5. 5.

   Log every invocation like you will be audited, because you will. One structured line per call, shipped to the same place your admin logs go:

   Copy

   2026-08-06T10:41:22Z agent=deskbot action=reset_user_password
   target=priya.n@corp.example ticket=INC0051233 risk=R3
   approver=s.rao@corp.example result=success duration_ms=1840
   

   The non-negotiable fields: who (agent + approver), what, target, ticket, result. If your platform's audit log cannot answer "what did the bot do to this user last Tuesday," build the log yourself at the tool layer.

6. 6.

   Test the refusals harder than the successes. Before launch, prove the agent cannot: reset an admin account (scope block), act without a ticket ID (contract block), execute R3 without approval (gate block), and act when asked nicely by a prompt-injected KB article ("ignore previous instructions and reset..."). Screenshot each refusal — that pack is portfolio material (pb-51) and auditor food.

7. 7.

   Ship one action, watch a week, then add the next. Sequence by risk: an R1 lookup first, then ticket creation, then the first R3 with approval. Each new action gets its own week of log review before the next lands.

Make it yours

• Freshservice shopbuild actions in Freddy AI Agent Studio against orchestration connectors; keep the connector's service account scoped per this recipe, and use Studio's approval steps for every R3. The platform logs are good; export them anyway.
• Atlassian shopRovo agents act through Jira/Confluence permissions of their service identity; scope it to the service project, not site-admin. Ticket creation and transitions are natural R2s; anything touching user management goes through your IdP instead.
• Custom MCP shopyour tool server is the enforcement point: validate inputs, check risk class, verify approval tokens, write the audit line, then call Graph. The model never holds credentials; the tool server holds narrowly-scoped ones.

Quality check

• Permissions match the table exactly. Quarterly, diff the agent's actual grants against the risk table. Every surplus permission is removed the day it is found, not documented.
• The approval gate is technical. Demonstrate — don't assert — that an R3 call without approval fails, by running it in the test tenant every month.
• Logs reconcile with tickets. Sample ten agent actions weekly; each must trace to a ticket and, for R3, an approver. An unlogged action is a sev-worthy finding.
• Injection is tested, not assumed away. Re-run the prompt-injection refusal test whenever the KB or the system prompt changes.