Protected-action guide
Use case
Observe the moment around a high-impact action
Use the same pattern for a password change, new payout destination, beneficiary creation, security-setting change, or sensitive data export.
Actions that can justify a focused profile
| Action | Server binding | Primary server controls |
|---|---|---|
| Change password or MFA | Security challenge ID | Recent authentication, factor verification, session rotation |
| Add payout destination | Payout setup ID | Account ownership, cooling period, beneficiary validation |
| Create beneficiary | Beneficiary draft ID | Step-up authentication, velocity, sanctions and business rules |
| Export sensitive data | Export request ID | Authorization, audit log, delayed delivery and notification |
Two-stage collection
Both collections use the same action_id. The first initializes Android UI observations; the second captures the final transaction context.
Mobile code
const protectedIntel = new DeviceIntel({
consent: consentFor([
"application",
"os_integrity",
"device_security_posture",
"transaction_safety",
"runtime",
]),
config: {
probes: {
transaction_safety: { enabled: true, timeoutMs: 900 },
},
},
});
// Screen entry:
await protectedIntel.collect({ sessionId: protectedAction.id });
// Immediately before commit:
const observations = await protectedIntel.collect({
sessionId: protectedAction.id,
clientId: authenticatedAccountId,
});The transaction probe can observe capture state, obscured touches, accessibility state, remote-access app matches, lock state, and call or audio state when available. Availability varies by platform and permission.
Action-bound request
{
"action_id": "protected_01JEXAMPLE",
"action_type": "protected_action",
"protected_action_type": "payout_destination_create",
"sdk_version": "0.8.1",
"platform": "android",
"observations": { "...RawSignalEvent": "..." }
}Authenticate the request and ensure the action belongs to the current account. Do not trust protected_action_type from the client when the server can derive it from action_id.
Backend decision boundary
Freshness
Compare collection time, observation-window timestamps, server receipt time, and action expiry.
Independent controls
Keep authorization, recent-auth checks, factor verification, transaction limits, and audit logging authoritative.
Graceful uncertainty
Route unusual or missing context to an appropriate step-up or review path instead of silently treating it as safe or fraudulent.