A Teams approval can look like a transfer of authority. It is not. Microsoft documents that Fabric Operations Agent queries and actions use the delegated identity and permissions of the agent's creator. Changing the recipient changes who sees and approves the recommendation, but it doesn't change the credentials used to read data or invoke the action.
This creates a production identity contract that must survive creator role changes, leave, termination, permission expansion, token or connection failure, recipient changes, action edits, and downstream system changes. A convenient human approval button does not compensate for an over-privileged or unmanaged execution identity.
If the creator left today, could you prove what the agent can read, which actions it can run, and how to stop it? Resolve that before expanding recipients or actions.
Define the creator identity and action contract
Record the human creator, employment status, Entra account, Fabric workspace role, Eventhouse or ontology permissions, KQL access, action permissions, downstream connections, Teams recipients, support owner, backup owner, review date, and stop authority. Calculate effective access rather than relying on assigned role names.
Separate four people or identities that the user experience can blur: the agent creator, the Teams recipient, the person who approves, and the downstream identity used by a Fabric item or Power Automate connection. Document every transition and prove which identity authorizes data access, recommendation delivery, action invocation, and downstream effect.
Make approval an explicit authorization boundary
| Control | Required evidence | Failure risk | Release decision |
|---|---|---|---|
| Creator | Named owner, approved role, effective source and action access, lifecycle status, review cadence, and backup. | Personal elevated access becomes a long-running automation credential. | Use a controlled least-privilege creator pattern approved for the current product behavior. |
| Recipient | Organization membership, agent-item write permission, direct message or Teams channel, duty role, availability, and substitution. | A broad channel or unqualified recipient can approve an action without ownership. | Restrict recipients to accountable responders and test membership changes. |
| Recommendation | Triggered condition, source evidence, rule and query, severity, action, parameters, expected effect, risks, and freshness. | The approver sees persuasive language without enough evidence to decide. | Require decision-ready context and an investigation route before approval. |
| Approval policy | Allowed approvers, Yes/No semantics, segregation of duties, escalation, expiry, out-of-hours behavior, and high-risk exclusions. | Any writer can authorize a sensitive creator-powered action. | Keep sensitive actions outside the agent or add a downstream authorization gate. |
| Parameters | Name, type, source, allowed values, range, current-state validation, editability, encoding, and sensitive-data handling. | An edited, stale, malformed, or model-generated parameter changes the target or impact. | Validate server-side against allowlists and current state; reject unknown or stale values. |
| Downstream action | Fabric item or Power Automate flow, connection owner, effective identity, permissions, idempotency, timeout, postconditions, and rollback. | The connection introduces broader authority or duplicate and partial effects. | Use a bounded action contract with independent authorization and observable result. |
| Audit evidence | Agent version, rule, query, source data, recommendation, recipient, response, creator identity, action input, result, duration, and incident link. | The team can't reconstruct who approved what authority and what changed. | Correlate the full operation before allowing production-changing actions. |
Microsoft currently allows direct Teams messages or channel posts. Recipient convenience must not redefine authorization. If the downstream system requires a stronger identity, dual approval, change window, or separation of duties, enforce that in the action service rather than relying only on the Teams response.
Test the complete action path and every negative case
| Test | Method | Pass condition | Remediation |
|---|---|---|---|
| Approved happy path | Trigger a known condition, inspect query and recommendation, approve with an allowed recipient, and reconcile the downstream result. | Only the intended creator authority, action, parameters, target, and effect occur once. | Correct identity, rule, action contract, parameter binding, or downstream connection. |
| Denied source access | Remove or narrow creator access to monitored data and trigger the rule. | The query fails visibly without stale inference, alternate-source leakage, or action execution. | Least-privilege source access, error handling, stop rule, or separate agent. |
| Denied action access | Remove permission to the Fabric item, flow, or downstream target while keeping source access. | No partial or hidden effect; failure is recorded and reaches the owner. | Permission correction, bounded executor, compensating action, or rollout block. |
| Recipient change | Change the individual and channel, then repeat query and action tests. | Delivery changes; creator-based execution authority doesn't silently change. | Recipient governance, write-permission review, and explicit approver authorization. |
| Parameter tampering | Edit values to boundaries, unknown entities, stale targets, restricted resources, malformed strings, and excessive quantities. | Server-side validation rejects unsafe inputs before any effect. | Types, allowlists, current-state checks, maximum impact, and encoding controls. |
| Duplicate approval | Repeat Teams interactions, retry after latency, send duplicate operations, and run concurrent approvals. | Idempotency key and state prevent duplicate execution. | Operation ID, lock, deduplication, postcondition, and compensating control. |
| Expiration and stale state | Delay response, change the target after recommendation, and test the documented three-day expiry. | Expired operations can't execute and stale parameters require revalidation. | Shorter business timeout, live-state check, regeneration, or escalation. |
| Creator offboarding | Disable the account, remove roles, rotate connections, transfer ownership, and restart the agent. | The agent fails closed, alerts an owner, and resumes only under an approved identity. | Lifecycle automation, backup owner, stop control, reauthorization, and acceptance test. |
| Downstream partial failure | Inject timeout, unavailable dependency, partial write, callback failure, and rollback failure. | Impact remains contained, observable, retry-safe, and recoverable. | Transaction boundary, idempotent retry, compensation, alert, and manual recovery. |
Keep the agent in recommendation-only or shadow mode until negative tests pass. Score detection, recommendation quality, approver comprehension, authorization, parameter safety, action correctness, duplicate prevention, failure containment, recovery, and audit completeness separately.
Govern creator, connection, recipient, and action lifecycle
A personal creator account is an operational dependency. Connect HR and identity lifecycle events to an agent inventory so leave, termination, role change, privilege increase, MFA or conditional-access change, and account disablement trigger review or stop. Define a supported ownership-transfer or rebuild procedure and test it before the creator becomes unavailable.
Review recipients and channels as approval surfaces. Microsoft currently requires recipients to belong to the organization and have write permission on the agent item. Reconcile write grants, Teams membership, duty roster, substitution, separation of duties, and sensitive-data exposure. Remove stale recipients and verify that revoked users can no longer receive or approve new operations.
Version goals, instructions, playbook rules, action descriptions, parameter schemas, source bindings, recipients, connections, and downstream versions. Monitor source-query failures, recommendation volume, approvals, rejections, expirations, duplicate attempts, action failures, permission changes, creator status, capacity, and unexplained state changes. Maintain stop, rollback, and incident runbooks for the agent itself.
Run a two-to-four-week identity and action security assessment
- Select one Operations Agent, creator, monitored source, recipient group, current recommendation flow, and bounded action set.
- Inventory effective source and action access, workspace roles, Teams delivery, agent-item write grants, connections, downstream identities, parameters, owners, and lifecycle events.
- Trace the control path from rule query and source evidence through recommendation, recipient, approval, creator identity, action invocation, downstream effect, and audit record.
- Define allowlists, parameter schemas, impact bounds, approval rules, timeouts, idempotency, postconditions, failure containment, rollback, and prohibited actions.
- Run allowed, denied, recipient-change, tampering, duplicate, expiry, stale-state, offboarding, connection, downstream-failure, recovery, and audit tests.
- Remediate creator privileges, recipient grants, action contracts, downstream authorization, parameter validation, lifecycle automation, monitoring, and stop controls.
- Deliver the identity map, effective-access evidence, action registry, test results, revised controls, operating runbook, incident and offboarding procedures, rollback, and go, limited pilot, recommendation-only, or stop decision.
Frequently asked questions
Which identity does Microsoft Fabric Operations Agent use for actions?
Microsoft states that Operations Agent uses the delegated identity and permissions of its creator. Queries, data access, and approved actions therefore run with the creator's credentials, not the Teams recipient's credentials.
Does changing the Teams recipient change Operations Agent execution permissions?
No. Changing the individual or Teams channel that receives recommendations doesn't change the identity used for queries and actions. A recipient can approve a recommendation, but the action still runs on behalf of the creator with the creator's permissions.
Who can receive Operations Agent recommendations in Microsoft Teams?
Microsoft's current documentation says recipients must belong to the organization and have write permission for the Operations Agent item. Messages can be sent directly to an individual or posted in a Teams channel, subject to the configured agent behavior and Teams app availability.
What happens if an Operations Agent recommendation isn't approved?
Microsoft documents that an operation expires when no action is taken within three days. After expiration, the recommendation can no longer be approved. Production design should also define escalation, substitution, rejection, duplicate-message, and stale-parameter behavior.
How long does an Operations Agent identity and action security assessment take?
A focused assessment commonly takes two to four weeks for one agent, creator identity, monitored source, recipient group, and bounded action set. It covers effective access, action contracts, approvals, parameters, negative tests, offboarding, audit, incident response, and rollback.
Official implementation references
- Create, configure, run, and audit Fabric Operations Agent
- Teams recipients, creator identity, Fabric item, and Power Automate actions
- Operations Agent identity, expiration, region, and runtime limitations
- Operations Agent responsible use and transparency guidance
- Operations Agent capacity and billing
Start with the action where the creator has broader access than the person approving it in Teams. Datrick can map effective authority, test the complete path, harden parameters and downstream controls, and define a recoverable production boundary.