Integration pattern · Illustrative scenarios and policy values. Confirm supported signals, processing location, and application enforcement for your deployment.
An agent’s API credentials show that software can call a service. A separate human approval can establish who authorized a sensitive request and what they approved.
BioTone adds a short-lived, signed authorization for an approved request. The receiving application checks it alongside its own credentials and permissions.
The agent can request authority, but the user sees the bounded action on their phone while the tenant console controls claim profiles, execution mode, TTL, and audit boundaries.
These demonstrations illustrate how human approval can fit an agent workflow. Confirm the current demo implementation and test the receiving system before using the pattern in production.
Scoped delegation
mediumThe assistant operates inside a narrow, human-approved policy. The user attests once for travel purchases under $500 in a 2-hour window; the agent finishes the booking without ever holding raw payment credentials.
Step-up signing
highA finance agent pauses before money moves and requires proof of live human authorization. The biometric check is bound to amount, beneficiary, and a 5-minute window — not just to the user's session cookie.
Anti-impersonation
highA CFO can require the caller claiming to be the CEO to complete a multi-signal check on their own phone. The recipient gets a cryptographic proof instead of trusting a cloned voice.
Human-approved artifact
mediumA newsroom or executive comms tool attaches a verified-human signature to the published artifact — so readers and downstream systems can verify a real principal approved it.
Machine-to-machine trust
criticalBuyer and seller agents negotiate; each side presents a short-lived BioTone proof that a human authorized this class of deal. Trust shifts from API-key possession to verified human authorization.
Configure the permitted request in the tenant policy and enforce approval at the receiving service. The agent initiates the request; it must not be able to bypass the enforcement.
BioTone is provisioned with tenant claim profiles: allowed scopes, token audiences, TTLs, execution modes, human-approval requirements, and audit boundaries. Your security team owns policy and audit; we operate the verification layer.
Require the receiving service to reject sensitive actions without a valid approval. An agent-side tool can initiate verification, but prompting an agent to call a tool is not an access control.
The tool reads the BioTone agent-protection discovery document and POSTs to the session endpoint. BioTone mints a deep link or QR code. The mobile app shows the user the action context, claim profile, execution mode, and expiry before biometric capture begins.
Capture runs on the phone; matching and liveness processing follow the selected deployment mode. Nothing about the action context is taken on faith: the user sees and approves the actual request, not just a generic “sign in?” prompt.
The broker returns a JWT carrying the action context, claim profile, execution mode, scopes, assurance level, principal subject id, and expiry. The agent attaches this proof to the downstream tool call — the receiving system verifies the signature, scope, freshness, and tenant policy before acting.
The broker returns a short-lived signed JWT. The agent attaches this token to the downstream call; the receiving system verifies the signature, audience, expiry, scopes, claim profile, execution mode, and that the action_context matches the operation it is about to perform. A token issued for one action cannot be replayed against another — scope, dataset, or execution mode mismatches are rejected.
// Illustrative claims on a BioTone agent-delegation JWT
{
"iss": "biotone-agent-auth",
"aud": "biotone-benchmark-runner",
"sub": "user_8f3c9b…", // your IdP-bound subject id
"iat": 1735690800,
"exp": 1735691100, // short — minutes, not hours
// BioTone-specific claims
"claimProfileId": "internal-pii-benchmark",
"executionMode": "controlled_execution",
"scopes": ["benchmark:job:create"],
"biotone_confidence": 0.91, // fused score for this attestation
"biotone_tier": 3, // 1=passive, 2=light, 3=full multi-signal
"biotone_confidence_at": 1735690800, // when assurance was established
"biotone_signals_passed": ["periocular","palm","voice","presentation"],
// The exact action being attested — never just "logged in"
"action_context": {
"purpose": "pii_vault_benchmark",
"scenario": "internal_benchmark",
"action": "create_benchmark_job",
"dataset": "biotone-demo",
"scope": "Create one controlled benchmark job",
"expires_in_seconds": 300,
"risk_level": "high",
"required_assurance": 0.82
}
}Exact claim names and signing configuration are deployment details. The shape above reflects the protected benchmark delegation path: the agent can create a controlled job without receiving decrypted PII-vault capture files.
What stays consistent regardless of which agent platform you run on top of.
Periocular, palm, ear, and voice support matching; pulse and presentation checks support liveness. Confirm the processing location and data retention for the selected deployment mode.
Every JWT is scoped to a specific action context. A token approving a $500 travel booking cannot be replayed against a $500,000 wire — the receiving system must reject scope or amount mismatches and enforce expiry and replay protection.
BioTone adds human approval alongside the application’s existing authentication and permissions.
Every attestation produces a record: who, when, action context, signals passed, assurance level, expiry. Your SIEM and IR playbooks see the same evidence the receiving system used to act.
For the underlying broker pattern and token-exchange semantics, see Developers → authentication broker. For Zero Trust posture and the relationship to continuous re-authentication, see Continuous re-authentication.
Bring one sensitive agent action. We will choose a demonstration and map the approval and enforcement needed for your integration.