A connector enables action. A delegation frame determines when, why and under whose responsibility that action is legitimate.
In brief
An autonomous team should receive no write access until its mandate, boundaries, approvals and evidence requirements are explicit. A sound frame does not try to predict every case. It classifies actions by impact, assigns a human owner and makes every exception visible, reversible and useful in a review.
Key points
- Define an observable outcome before choosing tools.
- Separate reading, preparation, reversible writing and committing actions.
- Trigger approval from impact, not an abstract confidence score.
- Record the source, rule, action, result and human decision.
- Expand rights only after reviewing errors and exceptions.
Why the mandate comes before the connector
A connector answers “what can the system do?” It does not answer “why is this action legitimate?” The NIST AI Risk Management Framework organises risk work into govern, map, measure and manage. Applied to an autonomous team, that sequence means understanding the work and its impact before enabling action.
The mandate should fit on one page and cover seven items: target outcome, authorised inputs, excluded cases, accessible tools, action level, human approval and retained evidence. “Manage follow-ups” is too broad. “Prepare follow-ups for opportunities with no activity for seven days, without sending messages or changing commercial terms” is testable.
Classify actions before assigning rights
| Action class | Control to apply |
|---|---|
| Observe an authorised record | Dedicated identity, scoped read access and access log |
| Prepare a summary or draft | Cited sources, completeness check and sampled review |
| Write reversibly | Idempotency, history, restoration and volume limit |
| Send, pay, sign or delete | Human approval, separation of duties and decision evidence |
This classification avoids a common failure: granting a broad technical role and trying to compensate with a text instruction. NIST SP 800-207 on Zero Trust Architecture instead supports explicit decisions about the subject, resource and context of access.
Design an approval rule people can use
A useful approval specifies the trigger, the decision owner and the decision packet. Reliable triggers are based on observable impact: amount, external recipient, sensitive data, contractual commitment, deletion, priority change or a missing required source.
The team should not simply ask “may I continue?” It should provide context, the proposed action, the applicable rule, supporting sources, alternatives and the consequence of rejection. Approval then becomes an informed decision rather than a compliance click.
Illustrative example: qualifying a supplier request
The following workflow is illustrative and does not claim a default product capability.
- The team reads a dedicated inbox and extracts authorised attachments.
- It checks whether the supplier exists in the reference system and flags inconsistencies.
- It prepares a record with amount, cost centre, missing documents and deadline.
- It may classify the case when all read and preparation rules pass.
- It suspends any purchase order creation or financial commitment.
- The procurement owner approves, rejects or requests a correction.
- The record links the original request, checks, decision and outcome.
The important design choice is not automating every step. It is separating preparation from commitment.
Define the minimum activity record
The record should let an independent reviewer reconstruct events without rerunning the system. Retain at least:
- the working identity and version of the rule applied;
- references to consulted inputs, without needlessly copying sensitive data;
- the tool called, requested action and result;
- the exception and escalation decision;
- the approver identity, timestamp and decision;
- the final business object that was created or changed.
The NIST AI RMF Playbook integrates responsibilities, monitoring and documentation into risk management. For an autonomous team, the activity record is both operational evidence and material for improvement.
Expand access in stages
Start with observation, then preparation. Next, allow reversible writing within a volume limit. Open a committing action only after defining its approval threshold, testing access revocation and reviewing simulated incidents.
| Stage | Promotion question | Stop signal |
|---|---|---|
| Observation | Are relevant inputs recognised correctly? | Out-of-scope access or misclassified data |
| Preparation | Are outputs complete and supported? | Frequent human rework or missing sources |
| Limited writing | Are changes accurate and reversible? | Duplicates, lost context or unexpected volume |
| Controlled action | Do approvals and escalations work under pressure? | Bypassed decision, incomplete evidence or ineffective revocation |
What to review every month
Do not review task count alone. Examine errors by severity, rework, new exceptions, unused permissions, approvals that are always accepted and cases that stopped in time. A control that is always approved may be a candidate for automation. A control that is often corrected signals an incomplete frame.
Conclusion
Framing an autonomous team creates a delegation contract. It connects a business outcome to an identity, rights, rules, approvals and evidence. The next step is to choose one observable workflow, complete the mandate sheet, then test revocation and escalation before granting write access.