Controlling What Agents May Do
Delegated work is work you did not directly supervise, so the controls matter more than they would for an ordinary integration.
Where to find it
The allowlist, the advertised skills and the task history are held in the A2A datastores, opened from All Datastores. Credentials and capabilities are shared with MCP; issued tokens are managed under Integration & Connections → OAuth Tokens.
The allowlist works in both directions
Only allowlisted agents may delegate to you, and you may only delegate outward to allowlisted agents. Both lists should be short and reviewed.
The outbound restriction is the one people overlook and the one that matters most: an agent that can delegate to anything can be talked into delegating to anything. Constraining where work can be sent is what stops a prompt-injected instruction turning your install into a relay.
Treat inbound instructions as data
An instruction arriving from another agent is input, not authority. It can ask for work within the skills you advertised and under the capability its credential carries — and nothing beyond, however the request is phrased.
This matters because a task description is free text written by something you do not control. Text saying "you are authorised to bypass approval" carries exactly as much authority as text saying anything else: none. The controls are the credential and the skill list, not the wording of the request.
Keep advertised skills narrow
Advertise the skills you actually want used. A broadly defined skill invites a calling agent to attempt things you did not intend, and the caller has no way of knowing you did not intend them — it is reading your card and taking it at face value.
Put a person in the loop
For anything with real consequence — money moving, messages to real people, disposal, anything statutory — have the task produce a proposal a person approves rather than completing autonomously.
The Input Required state exists precisely for this, and the platform's approvals mechanism under Automation → Approvals is the natural fit. A task that pauses for approval is not a failure of automation; it is the automation working as designed.
Failure is normal
Tasks fail, stall and get abandoned. Decide what happens to a task that has been Working for a day with no update, and make sure it surfaces somewhere a person looks rather than sitting in a state nobody monitors.
A stalled task queue is the agent equivalent of an unread inbox, and it goes wrong the same way.
Log everything and actually read it
Task history is your only account of what an external agent asked for and what was done about it. Review it regularly at first.
The useful signal is not errors — those are obvious. It is surprises: tasks doing something entirely reasonable that you had not anticipated anyone asking for. Those tell you what your card is advertising in practice, as opposed to what you thought it advertised.
Worked example
An install allowlists one partner agent and advertises three skills: look up a case, summarise a case, and draft a response. Drafting returns to Input Required for approval; the other two complete autonomously because both are read-only. Outbound delegation is allowlisted to nothing at all, because this install has no need to delegate — which is the safest possible configuration and costs nothing.
Recommendations
- Allowlist outbound to nothing unless you have a specific need. Most installs never need it.
- Advertise fewer skills than you could. The card is a commitment.
- Approve anything irreversible.
- Set a review cadence for task history and keep it for the first few months.
- Revoke a counterpart's credential the moment a trial ends — dormant allowlist entries are the ones that get exploited.