ActionProxy

approval use cases

Put approval between the drafted email and the send

An email approval flow is useful only if the reviewer sees the actual destination and content that will be sent. The decision should be tied to that payload, rechecked against current policy, and exchanged for narrow execution authority. In ActionProxy Community, a real send is performed by a configured external runner or downstream MCP server; Slack can be an optional notification and approve-or-reject surface, not the email executor.

For
Developers and operations teams adding human review to agent-generated customer or business email.
Reviewed
Jul 14, 2026
Length
1,253 words
An email envelope paused at a review checkpoint before continuing to a delivery service

Review the sendable payload, not the agent's intention

“Follow up with the customer” is not an approvable email. Your application should put every delivery-affecting field it uses—sender reference, recipients, subject, body, attachment references, reply-to behavior, and provider options—inside the proposed action. ActionProxy binds the fields that are submitted; it does not infer or validate a complete email-provider schema.

Keep the executor from rebuilding that payload from mutable state after review. If the recipient list, body, or another bound field changes, the original decision should no longer authorize the send. Submit the changed action again, or use a controlled edit flow that preserves both versions and re-evaluates policy.

Minimal HTTP proposal

{
  "toolName": "gmail.send_email",
  "agentId": "support-agent",
  "input": {
    "to": ["customer@example.com"],
    "subject": "Your refund request",
    "body": "We reviewed your request and..."
  },
  "reason": "Send the approved support response"
}

A defensible email approval lifecycle

  1. The agent or application constructs a typed send request. The gateway derives trusted tenant, requester, adapter, and environment context rather than taking those facts from the message body.
  2. Deterministic policy evaluates the tool and policy-relevant context. It can allow a narrow class, deny a prohibited class, or queue the action for approval.
  3. The approval record preserves the original input and binds it to the request, decision, policy version, reviewer requirements, nonce, and expiry.
  4. An eligible reviewer approves, rejects, or—through a surface that supports it—edits the payload. Edited input is evaluated again before authorization.
  5. Immediately before dispatch, ActionProxy rechecks the active state and produces one-use authority bound to the approved email and execution attempt.
  6. A configured external runner or downstream MCP server sends the message with its own provider credentials, then reports success, failure, timeout, cancellation, or an unknown outcome.
  7. The application shows the authoritative status. It does not tell the model that mail was sent merely because a reviewer clicked Approve.

Useful policy questions for email

  • Is the recipient internal, an existing customer, a new contact, or a broad distribution list?
  • Does the message contain prices, commitments, legal language, credentials, personal data, or security-sensitive instructions?
  • Is the sender identity appropriate for the requester, workspace, and environment?
  • Are attachments allowed, and are their immutable references included in what the reviewer sees?
  • Is this a first send, a reply in an existing case, or an automated follow-up whose timing matters?
  • Should this class be denied entirely rather than presented as something a reviewer can override?

Match the review channel to the decision

The local web queue is the canonical review surface. A single authorized reviewer can approve the original payload or submit edited input there; ActionProxy retains the original and approved identities and runs policy again. If an approval requires more than one decision maker, edited input is rejected today because the current model cannot safely carry votes across payload versions.

Slack is optional. It can notify a mapped reviewer and present a redacted payload with Approve and Reject buttons. The Slack callback enters the same approval service, but it does not edit the email. If a recipient, subject, or body needs correction, move to the canonical web review rather than approving in Slack and changing the message elsewhere.

Slack also does not send the business email. Approval notifications belong to the ActionProxy control plane; the configured external runner or downstream MCP server performs the provider action after authorization. Keeping those roles separate makes the audit trail easier to interpret.

Handle the uncomfortable outcomes explicitly

  • Rejection means the proposed email did not execute. Tell the agent whether to stop, request new input, or prepare a new draft.
  • Expiry or cancellation consumes the pending authorization. A later send requires a fresh submission and current policy decision.
  • Provider failure is different from rejection. Record the error without converting the human decision into a success claim.
  • A timeout after dispatch is ambiguous. Do not automatically send again; first check the action status and reconcile with the provider.
  • One approved send does not authorize a campaign, a changed recipient, or repeated delivery.

What you should be able to reconstruct

After the workflow settles, an operator should be able to correlate the proposal, policy result, review, receipt or grant, execution attempt, and reported outcome. Preserve both original and approved payload identities when an edit occurs. Keep the language modest: ActionProxy's local audit chain can detect changes relative to a trusted head, but it is not keyed or independently anchored, and its data-minimization controls are incomplete.

That record answers the practical incident question—what was proposed, who approved it, what crossed the executor boundary, and what result was reported—without pretending that an approval click proves inbox delivery or regulatory compliance.

Place this workflow inside the broader AI agent approval gateway boundary, use risk-based human approval to decide which messages need review, and follow the tool-call audit trail guide when designing the evidence path.

Common questions

Questions developers ask

Can ActionProxy Community send a real email by itself?

The bundled gmail.send_email name is a local mock. To deliver mail, configure an external runner or downstream MCP server to hold the provider credentials, perform the send, and report the outcome. Community does not include a native production email connector.

Can an approver edit an email from Slack?

No. Slack is a decision shortcut, not an editor: its card masks built-in secret-like keys and offers Approve or Reject. Open the canonical web review to change the content; that flow preserves both payload identities and runs policy again.

Should every agent-generated email require approval?

No. Separate drafts and internal previews from the tool that actually sends. Then write rules around the consequences that matter in your workflow—recipient class, message type, sensitive data, attachments, sender, and environment—and deny categories that review should never override.

What if the email provider times out after approval?

Treat the result as ambiguous, not failed. Check the existing action and reconcile with the provider before another send. ActionProxy can record an unknown outcome, but Community neither retries it automatically nor supplies provider-side idempotency or reconciliation.

Continue the path

All guides →