An OAuth connector needs a callback. During local development, the service sending that callback may not be able to reach the developer's machine directly. A tunnel can bridge the gap, but it also changes how a local endpoint is exposed.
MFA automation raises a second question: which identity can access the seed used to generate one-time codes?
Two decisions, not one
The callback. A public tunnel can route traffic to a local service. Access depends on the tunnel provider, the destination's authentication and the network configuration. Register the exact callback address, limit its lifetime, and validate the OAuth state and redirect URI.
The MFA seed. A time-based one-time password is derived from a shared seed. If the same automation holds the password and seed, a compromise of that automation can expose both. Use isolated test identities for automated login flows and restrict who can read their seeds.
These controls serve different purposes. Protecting the MFA seed does not secure the tunnel, and restricting tunnel access does not decide who can authenticate.
Give the agent a supported path
Provide a managed callback endpoint or approved tunnel with an owner, access policy and expiry. Use service accounts or supported delegated authorization for production integrations. When a human login is required, give the agent a way to request it instead of asking it to improvise credentials.
Log the creation and removal of external endpoints, authorization requests and secret access. With those records, a security engineer can connect the endpoint, identity and task without recording a token or MFA seed.