Been running the OpenAI Operator in our staging environment for about three months now, primarily for automating customer support ticket categorization and initial responses. Like many of you, we started with the built-in `gmail-tool` for sending notifications and updates. It was convenient, but the lack of granular control and visibility started giving our security team (and me!) heartburn 😅.

We've now fully migrated to a custom SMTP relay we built internally, and the difference is night and day. The `gmail-tool`, while easy, essentially means delegating your SMTP auth secrets to the OpenAI runtime. You have little to no control over logging, queue management, rate limiting, or detailed telemetry on delivery attempts. With our own relay, we've baked in full Prometheus instrumentation, per-tenant rate limiting, and mandatory TLS with specific cipher suites. The operator now authenticates to *our* service, which then handles the actual delivery to Gmail (or other providers).

Here's a snippet of the updated `OpenAIOperatorConfig` we're using:

```yaml
tools:
- type: custom_smtp
name: notification_sender
config:
relay_host: "smtp-relay.internal.net:587"
auth_type: "bearer_token"
token_secret_ref: "openai-operator-smtp-token"
require_tls: true
max_retries: 3
timeout: "10s"
telemetry_endpoint: "http://telemetry-collector:8080/metrics"
```

The key changes from a security perspective:
* **Authentication:** We moved from a static Gmail password in the secret to a short-lived, scoped bearer token that our relay validates. The relay service has its own service account for Gmail.
* **Action Control:** The operator can now only send via our relay. The relay enforces policies—no sending to high-risk domains, size limits, and it adds disclaimers to all outbound mail.
* **Telemetry:** Every send attempt, success, or failure is logged with a correlation ID that ties back to the specific operator pod and source request. This is golden for anomaly detection.

Performance-wise, we saw a slight increase in latency (~+15ms median), but the trade-off is worth it. We now have dashboards tracking:
* Tool call volume by operator instance
* Relay latency percentiles
* Failure modes (auth, network, recipient rejection)
* Unusual send patterns (potential indicator of a compromised agent)

For anyone running this in a compliance-heavy environment (HIPAA, GDPR), this pattern is, I'd argue, essential. It prevents the OpenAI-hosted agent from ever holding direct credentials to your third-party services and creates a critical audit and control point. Has anyone else moved away from the built-in tools for similar reasons? I'm particularly curious about how you might be handling the auth token rotation for the relay.

- Aisha