Blocks Network Security.

Zero Trust by design, not by configuration.

The Blocks Network is built on Zero Trust principles: no implicit trust based on network position, continuous verification on every request, least-privilege scoping at every credential boundary, and the assumption that any individual credential may already be compromised. Concretely:

1. 01Identity is proved on every request, not just at sign-in. A leaked credential has a short window of usefulness.
2. 02Tokens are scope-limited and time-limited at every layer. Holding a token to one resource grants nothing on another.
3. 03Revocation propagates in seconds. Sign-out, role change, key rotation, and account deletion all take effect within seconds, not when a token would otherwise expire.
4. 04Transport is encrypted everywhere, with optional end-to-end encryption between Callers and Provider Agents on top of TLS.
5. 05Data is tenant-scoped, retained for 90 days, and isolated by organization at every layer of the stack.
6. 06Compliance is inherited from PubNub: SOC 3, SOC 2 Type II, ISO/IEC 27001, HIPAA, and GDPR data-subject rights. Reports live at the PubNub Trust Center.

Identity is durable; credentials are not.

› Terminology

• Caller is anything calling an agent. A Caller may be a human (signed in via the dashboard or a custom app) or another agent making an agent-to-agent (A2A) call.
• Provider Agent is the agent doing the work: the entity receiving the call and producing the response. Often shortened to “the agent” when the context is unambiguous.
• User is reserved for human identity (sign-in, password handling, MFA), since those flows are human-specific.
• Consumer org (billing) is the organization paying for agent services. Provider org is the organization that owns / operates the agent. These names are unchanged from how billing surfaces describe them.

In the SDK and wire-level API, the Caller role appears as Consumer (Consumer SDK, consumer JWT, /auth/agent/consumer-token). Marketing-facing materials, including this document, use Caller. They refer to the same role.

› Sign-in methods

Blocks separates identity (a long-lived account relationship) from credentials (short-lived proofs minted from that account). The platform supports three sign-in shapes, all backed by the same identity system:

• Passwords are hashed, never stored in plaintext. Email + password accounts must verify their email address before they can sign in. Plaintext passwords never touch the database or the logs; Blocks holds only the hash. Users who sign in through Google or GitHub inherit account-takeover resistance from those providers, including their MFA settings.
• API keys are server-side only. Keys never go to browsers or mobile clients. For client-side applications, the developer deploys a thin token-minting proxy that identifies its own end users and asks Blocks to mint a scoped access token. The API key stays on the developer's server (see §3.3).
• Session cookies are revocable server-side. Signing out deletes the session row immediately; any access token minted from that session stops working within seconds.

› 1.1 Cross-site request forgery (CSRF)

Dashboard mutations are protected against CSRF using a session-bound, double-submitted token. A CSRF token minted in one session cannot be replayed in another. SDK and CLI traffic, which uses bearer tokens rather than session cookies, is unaffected by this machinery.

Four mechanisms. Checked on every call.

Authentication says who; authorization says what they can do. Blocks layers four mechanisms.

› 2.1 Roles

Inside an organization, members hold one or more roles that determine their capabilities:

Roles are derived from organization membership and permissions, not assigned individually. This keeps the authorization model in lock-step with how organizations work.

› 2.2 Ownership

When a Caller submits a task, the task is bound to that Caller's identity. Other Callers cannot read, modify, or cancel that task; the Provider Agent's organization and platform support staff can read it on appropriate channels, but not manipulate it. Ownership is checked on every operation, not just at task creation.

A Provider Agent can additionally declare end-to-end encryption between the Caller and the agent handler (§5.2). When an agent operates in this mode, task inputs and outputs are encrypted to a key the Caller controls, so even the read access the Provider Agent's org and platform support staff have on the underlying channel sees only ciphertext.

› 2.3 Private agents

Agents can be marked private, restricting visibility to the agent's owning organization:

• To non-members, the agent appears not to exist. The platform returns a not-found response rather than a permission error, so agent names cannot be probed for existence.
• To members of the agent's organization, the agent is visible and callable.
• Platform support staff can read private-agent metadata for troubleshooting, but cannot perform actions against private agents in another org. The platform enforces an active-org match on call paths even for admins, to prevent accidental cross-org changes.

› 2.4 Invitation-based sharing

Agent owners can share a private agent with an external user or organization by sending an invitation:

• Invitations carry a one-time, time-limited token (single-use, 7-day expiry).
• The accept link requires the recipient to be signed in; token possession alone is not sufficient.
• Once accepted, a grant record is created (scoped to either a user or an organization).
• The agent owner can revoke the grant at any time. Revocation takes effect on the next request. There is no token to invalidate and no cache to wait out.

› 2.5 Sensitive endpoints require dashboard sessions

A small set of operations (API key management, payment-method operations, payout initiation, and payout-account metadata) accept only dashboard sessions. Bearer-token Callers (CLI, SDK, agents) are rejected on these surfaces even if otherwise valid.

This prevents the situation where a leaked machine credential could be used to rotate the keys it depends on, mint billing-portal links, or move money. Money and credential management stay in the dashboard's reach only.

Long-lived identity, short-lived proofs.

Every operation in Blocks follows the same general pattern:

1. 01Establish identity with a long-lived credential (dashboard session, API key, or invitation grant).
2. 02Exchange it for a short-lived access token scoped to the operation about to happen.
3. 03Use the access token for the operation, then let it expire.
4. 04Refresh or re-mint when needed; never reuse a token past its intended boundary.

The platform never asks a Caller to manage long-lived secrets in client-side code. Different Caller shapes follow this pattern slightly differently:

› 3.1 Dashboard Callers (human users)

A signed-in user calls Blocks APIs using their session cookie. When the dashboard needs to subscribe to real-time updates, it mints a short-lived streaming token (≤ 60 minutes) scoped to the user's visible channels. The token auto-refreshes a few minutes before expiry. The user never sees this happen.

› 3.2 Server-side Callers (SDK)

A backend application (or another agent making an A2A call) holds a Blocks API key. On first use, the SDK exchanges the key for a short-lived access token (60 seconds) and a refresh token. Every subsequent operation uses the access token; the SDK rotates it transparently before expiry.

Single-use refresh-token rotation means that if either the legitimate Caller or an attacker uses a refresh token, the other one is forced into a fresh sign-in flow the next time they try. Token theft is self-detecting.

› 3.3 Client-side Callers (browser / mobile)

API keys never go to browsers or mobile apps. The supported pattern is a developer-owned proxy: the developer deploys a thin backend endpoint that identifies its own end users (cookies, SSO, whatever), then asks Blocks to mint a scoped access token. The Blocks API key stays on the developer's server; the client-side application only ever holds short-lived access tokens that the SDK refreshes automatically.

› 3.4 Provider Agents (the agent runtime)

A Provider Agent runtime holds its own Blocks API key in its environment. On startup, the SDK exchanges the key for an access token plus a streaming credential that lets the agent receive task dispatch messages and publish results. Both are time-limited; the SDK refreshes them transparently. When the Provider Agent reads a task, the streaming credentials in play are scoped to that specific task. They do not authorize the agent to read other tasks or other customers' channels.

› 3.5 Per-stream credentials for streaming tasks

Long-running tasks that produce or consume real-time streams (audio, video, telemetry, sentiment feeds) receive per-stream credentials:

• Each stream gets its own pair of access tokens: one for the Provider Agent side, one for the Caller side.
• Tokens are direction-aware: outbound streams grant only write to the producer and only read to the receiver (and vice versa).
• Operators can revoke an individual stream's credentials to stop a specific stream without terminating the task it belongs to.

This is the same principle as the rest of the platform: credentials exist at the granularity of the operation, not the granularity of the Caller.

› 3.6 File uploads

Files attached to tasks (Caller input, Provider Agent output) are uploaded directly to managed object storage using time-limited, one-time pre-signed URLs. The file bytes never flow through Blocks' API servers. Properties:

• Upload URLs expire after 15 minutes.
• A second confirmation of the same upload is rejected.
• Anonymous (signed-out) Callers cannot upload.
• Downloads require an authenticated streaming credential; static file URLs are not browseable.

› 3.7 Reconnecting to a task

A common pattern: a Caller submits a task on one device, comes back later, and wants to subscribe to the result on another. The SDK provides a connect method that takes a task ID and the Caller's existing identity; Blocks verifies ownership and issues a task-scoped streaming credential good for the rest of the task's lifetime.

Re-verified on every request. Revoked in seconds.

A signed token is necessary but not sufficient. Every authenticated request runs through three independent rechecks after signature verification:

1. 01Session check. For tokens minted from a dashboard session, the platform confirms the session row still exists.
2. 02Organization-membership check. The platform confirms the identity behind the token is still a member of the org the token claims.
3. 03Denylist check. The platform supports immediate per-token revocation by adding the token's identifier to a denylist.

This is the Zero Trust principle of continuous verification, applied per-request rather than at token mint time. A 5-second in-memory cache keeps this from adding a database round-trip to every call.

› 4.1 Revocation time-to-effect

Most window-sizes are determined by the natural expiry of a short-lived token (60 seconds) plus a small caching buffer. They are not dependent on the Caller noticing or refreshing.

› 4.2 Per-stream and per-task revocation

Because streaming credentials are minted per-stream and per-task, operators can:

• Stop a single stream without terminating the task it belongs to.
• Terminate a task without affecting the agent's other tasks.
• Disable an agent without affecting the rest of the organization.

The blast radius of any single revocation is exactly the scope it needs to be.

TLS by default. End-to-end when you need it.

› 5.1 Transport encryption

All traffic in Blocks runs over TLS: REST APIs, real-time channels, and file uploads alike. There is no plaintext path.

› 5.2 Optional end-to-end encryption between Caller and Provider Agent

A Provider Agent can declare in its agent card that it supports end-to-end encryption between the Caller and the agent handler. This is useful when:

• The provider wants ciphertext-only delivery beyond TLS.
• The Caller wants responses encrypted to a key only they control.
• Compliance posture requires application-layer encryption regardless of transport.

When an agent declares encryption, the agent card specifies:

• The algorithm (e.g. x25519-xsalsa20-poly1305, rsa-oaep-256).
• Whether the Caller must supply their own public key on every submission.
• The agent's public key (or a URL to fetch it, supporting key rotation).
• A documentation URL where the provider documents envelope format and framing.

The platform's role is to declare the capability, validate that required keys are present, and pass keys through to the agent handler. The handler implements the actual encryption. This split lets providers choose algorithms appropriate to their use case (financial, healthcare, defense) without the platform becoming an opinionated cryptographic runtime.

› 5.3 Signed agent discovery

Agents serve their public profile at a well-known URL. When an agent is mirrored to third-party catalogs or fetched across organizations, the profile can be signed with the agent provider's key (ES256 or EdDSA). This lets external verifiers confirm that the profile they received is the one the provider published.

Tenant-scoped. 90 days. Encrypted at rest.

› 6.1 Where data lives

Customer data on the Blocks Network lives in four storage tiers:

Every customer-data record carries an organization ID. The authorization layer scopes every query to the Caller's active org; records from one org are never returned to another, even if the Caller is otherwise authenticated.

› 6.2 Retention

Platform retention policy: 90 days. Task records, file artifacts, message history, and operational logs are retained for 90 days. Billing records (invoices, ledgers) are retained per applicable financial-records requirements, which typically exceed 90 days. Identity records track the lifecycle of the account itself.

Short-lived records (sessions, refresh tokens, file upload URLs, invitation tokens) have shorter expiries tracked on the record and pruned automatically.

› 6.3 Encryption at rest

Storage is encrypted at rest by default through PubNub's managed infrastructure. See §6.5 for the audit and attestation lineage.

› 6.4 Geo / IP handling

When an agent comes online, the platform records the agent's IP for operational debugging. The raw IP is never returned in API responses. Only derived city and country fields are visible to the agent's organization. The integration test suite explicitly verifies that raw IPs do not leak through any API response.

› 6.5 Compliance & data-subject rights

The Blocks Network is operated by the PubNub team on PubNub's infrastructure. The platform inherits PubNub's compliance posture and data-subject rights program in full:

• SOC 3 (publicly available report)
• SOC 2 Type II (available under NDA)
• ISO/IEC 27001
• HIPAA (Business Associate Agreement available where applicable)
• GDPR data-subject rights: access, rectification, erasure, portability, restriction, and objection

The authoritative source for current certifications, reports, and data-subject-rights procedures is the PubNub Trust Center at https://www.pubnub.com/trust/. Treat the Trust Center as the canonical reference for everything in this subsection.

Default-off. Sensitive data never reaches the wire.

The Blocks Network sends error events and a thin slice of performance traces to a self-hosted observability platform. The Sentry SDK configuration scrubs all sensitive data before any event leaves the application:

What observability can see: code paths where errors happened, endpoint paths, query parameter names, and timing data.

What it cannot see: who triggered the error, what data was passing through, what credential was in use, or what cookies the user held.

Telemetry is also default-off. Without a deployment-time configuration, the SDK initializes as a no-op and nothing leaves the application at all.

No implicit trust, anywhere, ever.

The architectural choices in this document all serve a single operating principle: no implicit trust, anywhere, ever. In practice, every operation passes through multiple independent gates:

A request that survives every gate is authorized. A request that fails any single gate gets a deterministic error: no leaks via timing, no enumeration via 404-vs-403 divergence on sensitive endpoints, no information disclosure via error messages.