Power Platform

A custom connector so Power Automate flows and Logic Apps can verify - and govern - real agent identities, with zero code and zero infrastructure.

The pain

Your Power Automate flow just received a webhook from something claiming to be an autonomous agent - an approval callback, a payment trigger, a step in a Copilot Studio pipeline. The trigger carries a source IP.

You have no low-code way to answer the only question that matters - is this a real, currently-provisioned agent, or a spoofed request from anywhere on the internet? - without dropping into an Azure Function, wiring up raw HTTP actions with hand-built headers, and parsing whatever comes back.

Multiply that by every flow that touches agent traffic and you've built the same bespoke verification a dozen times: none consistent, none getting the DNSSEC/DANE chain right, and none able to actually provision or shut down the agent when you find a problem.

Whisper closes that gap with one thing: a proper Power Platform custom connector - an Independent Publisher connector, Whisper Agent Identity - that gives every flow a native action for identity verification, and, if you supply an API key, native actions to register, list, police, and revoke agents. No Azure Function, no raw HTTP action, no hand-rolled header. Drag the action into the canvas, fill in two fields, done.

The standard underneath: what "verifying an agent" actually checks

Whisper agent addresses are real, routable IPv6 /128s allocated out of 2a04:2a01::/32 (announced by AS219419). "Is this address a real Whisper agent" is not a lookup in a proprietary table - it's a chain of open, independently-checkable steps, all run server-side for you by the keyless verification endpoint:

1. Reverse DNS (PTR) - the address reverse-resolves to a canonical name like acef2002a323d40d4.<tenant>.agents.whisper.online (reverse DNS per RFC 1035, with IPv6 ip6.arpa delegation per RFC 3596).
2. Forward-confirming reverse DNS (FCrDNS) - resolving that PTR name's AAAA record must round-trip back to the original address, so a PTR alone (which anyone can point anywhere) proves nothing without this forward check.
3. DANE-TLSA pin (RFC 6698) - a TLSA record under the agent's name pins its TLS certificate (3 1 1 = DANE-EE, SHA-256 of the SPKI), so the name can't be MITM'd even if a CA is compromised.
4. Signed identity document - an ES256-signed JWS binding the address, the hostname and the issuing tenant, checkable against Whisper's published fleet key.

The keyless endpoint runs all four steps and returns one verdict - is_whisper_agent, dane_ok, jws_ok, plus the supporting evidence - so a flow author never has to orchestrate the chain by hand. Full mechanism: /docs/verifiable-identity and /docs/dane.

The raw HTTP calls the connector wraps

Every keyless operation is one plain HTTPS request - you could reproduce all of this in a flow with raw HTTP actions and manual JSON parsing, which is exactly the boilerplate the connector removes.

# Verify identity end-to-end (PTR + FCrDNS + DANE + signed doc)
GET https://rdap.whisper.online/verify-identity?ip=2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4
# { "is_whisper_agent": true, "fqdn": "acef2002a323d40d4.<tenant>.agents.whisper.online",
#   "dane_ok": true, "jws_ok": true, ... }

# The RDAP record (RFC 9083)
GET https://rdap.whisper.online/ip/2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4

# Register / list / revoke (the control plane) - one Cypher verb over HTTPS
POST https://graph.whisper.online/api/query      # header: X-API-Key: whisper_live_xxx
{ "query": "CALL whisper.agents({op:'register', args:{label:'invoice-bot'}})" }

The full terminal walk (with dig/openssl) is on Verify an agent - but in Power Automate you never leave the flow.

With Whisper: the custom connector

The connector ships as an Independent Publisher connector - Whisper Agent Identity - importable straight from the swagger definition, or (once merged) discoverable in the Power Platform connector gallery like any first-party connector. The connector package is a swagger/OpenAPI definition plus its connection properties, importable straight into Power Platform; the Independent Publisher submission is pending review.

One connection, two tiers

There is exactly one connection parameter: Whisper API key (securestring, optional). Per Postel's Law - be liberal in what you accept - the connector works with it blank:

Under the hood the key is attached to the nine operations that reach the Whisper control-plane host (five control, four graph), via a header policy that fires on those operation IDs; the four RDAP actions never see it and never need it. The four graph actions do get the header, and answer anyway when it is blank: a blank X-API-Key reads exactly like an absent one, so the graph tier stays keyless and a key only lifts its limits. An anonymous call to a control action doesn't 500; it comes back as a clean, structured error: "anonymous callers cannot use the agent control plane - an attributable API key is required." That's the Robustness Principle showing up as a design decision, not a slogan: the connector is strict about what it emits (a typed, documented, RFC-conformant reply) and permissive about what it accepts (key or no key, same connector, same actions visible).

The thirteen actions

Keyless identity, served from rdap.whisper.online:

Keyless graph, served from the Whisper graph endpoint, no key needed:

The value you type is bound as a $ parameter rather than pasted into the query text, so a hostile string fills its slot and never becomes syntax. The anonymous tier runs one query at a time and truncates large results; a key lifts both, and is never required.

Control, served from the Whisper control plane, require the key:

Each control action carries a query field pre-filled with the exact whisper.agents Cypher CALL for that operation - you edit the values inside args (the label, the policy lists, the agent id) directly in the flow designer; the connector POSTs {"query": ...} to the control plane verbatim. This is a deliberate design choice: rather than reinvent a bespoke schema per action, the connector exposes the same control verb documented in /docs/control-plane, so what you learn in Power Automate transfers directly to the CLI and every other SDK.

A flow: verify on trigger, revoke on failure

A minimal but real flow - an HTTP-trigger flow that gates on agent identity before doing anything else:

1. Trigger - When an HTTP request is received, body includes source_ip.
2. Action - Whisper Agent Identity → Verify agent identity, ip = triggerBody()?['source_ip'].
3. Condition - is_whisper_agent == true and dane_ok == true. - Yes → continue the business flow (e.g. approve the payment). - No → Whisper Agent Identity → Revoke an agent (if you provisioned it) or route to a Teams/email alert with the detail field from the verdict.

Swap step 2 for RDAP lookup if you only need the registrant/country/status fields, or add Get inbound identity lookups as a scheduled flow to build a lightweight per-agent access dashboard entirely inside Power BI, fed by a Power Automate recurrence trigger - no separate ETL job.

Installing it

Until the connector lands in the shared gallery, import it as a custom connector from the swagger definition:

1. Power Automate → Data → Custom connectors → New custom connector → Import an OpenAPI file.
2. Upload the connector's apiDefinition.swagger.json (host rdap.whisper.online; the five control and four graph operations are dynamically re-hosted onto the control plane by a dynamichosturl policy template). The submitted package, all three files, is public in the review PR: #4225 file list.
3. Create a connection; paste your whisper_live_... key if you want the control actions, or leave it blank for keyless-only.
4. Test each action from the connector's Test tab before wiring it into a flow.

Related integrations

If your automation platform is Dify rather than Power Platform, the same two-tier keyless/keyed model ships as a Dify plugin - see /docs/integrations for the full no-code matrix (n8n, Zapier, Make, Pipedream, Dify, Power Platform). All of them call the identical public endpoints and the identical whisper.agents control verb described here - there is one control plane, not six.

Next: Verifiable identity for the full verification-chain mechanism, or Control plane for every whisper.agents operation the control actions map to.