Per-agent identity. Per-call signature. Zero static secrets.

ScrambleID for non-humans doesn't replace your IdP. It adds the per-call signature layer your IdP can't deliver. The agent's identity binding can derive from your IdP's principal model, federated via OIDC or SAML. The signing keys are scoped to the runtime and per-call, not to the IdP session.

No. The signing primitive runs as a library in your agent runtime. Enclave-backed signing is supported as a hardening option but not required for production. Most pilots ship without it and add it later when threat-model maturity demands.

The agent still constructs the signed authentication request, even when steered. The signature binds the request to the runtime fingerprint and the request context, not to the agent's reasoning. The verifier sees the runtime fingerprint and the context hash on every call; a compromised reasoning loop doesn't change either. The credential isn't a token the attacker can replay; it's a runtime-bound signature the runtime produces at the point of call. The compromise becomes detectable at the next call from that runtime, with attribution intact.

AI agents (any LLM runtime), machines (cron, batch, ETL, infrastructure callers), bots (UiPath, Automation Anywhere, Power Automate, RPA), and workloads (containers, functions, ephemeral compute). Anything that holds a credential and acts on its own behalf gets the same primitive. Service accounts aren't a separate runtime: they're a use case. A service account is the IAM identity one of these runtimes carries, and replacing its static credential is one of the most common reasons teams start here. The SDK targets are the runtimes; the model is uniform.

Yes. ScrambleID for non-humans is one cryptographic identity layer across all three. Enterprise AI deployments use it for internal agents acting on workforce behalf: IT automation, security operations, finance bots, and any LLM runtime that executes privileged actions inside the tenant. B2B agent-to-agent interactions use it for cross-organization agent calls, vendor agents acting in a customer tenancy, and federated supply-chain automation, with the same federated trust roots that govern human cross-org auth. Consumer-facing AI products use it for customer support agents, transactional shopping agents, and AI assistants that take actions on behalf of named end-users, signing with the same primitive regardless of who they act for. UiPath, Automation Anywhere, Power Automate, and any LLM runtime sign and verify against the same primitive. One identity model for every non-human caller, regardless of who they act for.

Agents from different organizations can verify each other's signatures via federated trust roots, the same model as TLS PKI. Your trust roots decide which outside-organization principals you accept and on what conditions. This makes vendor-integration agents attributable across the trust boundary.

Signing and verification add latency that fits inside the API call's existing SLO budget. Per-environment numbers depend on the key-management mode (in-process vs. enclave-backed) and the hardware profile. We can share specifics once your team's runtime profile is known.

Pilot: install the SDK in one runtime, point the verifier at your dev IdP, and validate the first signed requests. Time to first authenticated request: hours, not days. Production: extend across your other runtimes and federate the verifier into your CI/CD. Identity bindings are committed alongside the agent code, so every change is diff-able, versioned, and reviewable in the same repo. Time to full production: weeks.

Yes. Vendor agents register their runtime fingerprints with you under your federation policy. The signing primitive is the same. Your verifier accepts vendor signatures based on the trust roots you configure, the same way TLS PKI federates across organizations.

The signing key is held in the runtime, not on disk or in a config file. A compromised runtime is a credential exfiltration event scoped to that runtime instance, not a credential leak that spreads. The runtime fingerprint in the signed payload makes the compromise detectable on the next call from that runtime, before the compromise spreads.

The frameworks converged on the same demand: agents need their own identity, scoped authority, and an audit trail that holds up. The OWASP Top 10 for Agentic Applications puts identity and privilege abuse at ASI03 and rogue agents at ASI10; per-agent identity with per-call signatures answers both, because an agent that can't mint unsigned calls can't operate beyond its scope or off the books. A February 2026 NIST NCCoE concept paper on AI agent identity and authorization calls for tying every agent action back to an accountable identity, auditable and non-repudiable: that's the signature in the request, not a log line after it. And the Cloud Security Alliance's AI Controls Matrix, 243 control objectives across 18 domains, presses the same identity and accountability gaps. Zero static secrets closes the path ASI03 names; the signed call closes the attribution gap the rest of them circle.