Skip to content
Pyrana

Security and trust

Authorization is decided on the backend, in layers.

Every call to a Pyrana App passes one gate, takes one authorization path, and writes one execution record before it runs. The page only reflects the outcome. Facts that still need sign-off are marked to confirm.

  • SOC 2 aligned
  • Private tenant or client infrastructure
  • No training on client data
  • SSO · Entra ID · OAuth
  • Tenant isolation with RLS

To confirm before publication

  • · Penetration test firm and date
  • · SOC 2 audit status and report availability
  • · Subprocessor list
  • · Data residency regions offered
  • · Retention periods for data, content, and telemetry
  • · SIEM export path
  • · Security contact address and disclosure policy

01Vocabulary

Client data. Client content. Platform telemetry.

Three different things with three different homes and three different readers.

Client data

What
Records, credentials, and identities an App is bound to: the ledger, the CRM, the project graph in a client extension.
Where it lives
Stays in the client's systems and the extension's own storage. Agents query it live through tool sources; the platform does not need to store it.
Who can see it
Callers with a matching access profile and scope entitlement. Anything else is absent from results.

Client content

What
Documents and conversations that become Context Units, and the resources an App publishes.
Where it lives
cortIQ stores Context Units in the client's deployment. Resources are versioned and held under the App that produced them.
Who can see it
Authorization is applied before retrieval returns, so an unauthorized unit is absent rather than redacted.

Platform telemetry

What
Operational metadata needed to run, audit, and evaluate: gate decisions, tool calls, approvals, effects, context accounting, traces and tokens.
Where it lives
Audit and telemetry records in the client's deployment, written before execution. Available as JSON.
Who can see it
Tenant administrators and the auditors they grant access to.

02Identity and access

The identity the enterprise already runs, extended to agents.

People arrive through SSO (Entra ID, OAuth). Services arrive with OAuth client credentials. Identity is explicit: an agent with its own identity, an agent on behalf of a user with a delegated token that names both, a workflow as a service principal. Nothing in the chain is flattened into a shared account.

Authorization is decided in five layers, all on the backend. Each layer narrows the one above it, and the frontend only reflects the result.

  1. 01TenantThe hard boundary. Row-level security in Postgres; every query carries the tenant.
  2. 02App membershipA caller belongs to an App or does not. An App a caller is not a member of reads as absent.
  3. 03Access profileWhat a member may do in the App: read, run, approve. Reading a record and approving a change are two different permissions.
  4. 04Scope entitlementWhich entity, project, or review queue the profile applies to. Tool policies map the entitlement to tool arguments before the call.
  5. 05Approval lanesConsequential actions route to a named group before they execute. A queued request is visibly different from a posted entry.
Enforced bySSOrow-level securityOpenFGAaccess profilesscope entitlementsdelegated tokens
actor chain · one call
initiator
maya.chen · sso:entra-id
app
finance-close@v14
agent
agent:close-reviewer · own identity · delegated for maya.chen
tool
tool:ledger.journal.post
authority
child ⊆ parent · live policy re-checked
credential
erp connection held by platform · never by the agent or extension

Illustrative. Pyrana Capital is a synthetic portfolio.

03Application security

What an App may do is decided per call, at the gate.

One gate admits every call, whether it arrives from a page, the copilot, the API, MCP, a schedule, or an external event. The same eight steps run for a person and for an agent.

application security
gate · tool policy · effects

  • One gate, fail closed

    Every call through every door passes eight steps before dispatch: identity and idempotency key; active App version; target exists and caller allowed; page and resource references resolved to exact versions; one authorization check; idempotency claimed and the execution row and audit record written in one transaction; dispatch to the native host; outcome recorded. Any uncertainty is a refusal.

  • Identity is explicit

    An agent with its own identity, an agent on behalf of a user, a workflow as a service principal. All three take the same authorization path, and a child call never exceeds its parent's authority.

  • Tool policies before the call

    Tool policies map a caller's scope entitlement to tool arguments before the tool runs. Above a threshold the invocation freezes and routes to a named lane; the frozen call is revalidated before it dispatches once.

  • Extensions reachable only through the platform

    Client-owned durable services run in the same cluster, built with the platform library that handles authentication and authorization up front. Not publicly accessible. Outbound actions are performed by the platform with platform-held credentials.

  • Secrets never in prompts

    Connector credentials are held by the platform. Prompts carry references, not secrets. Model calls go through the client's keys to the providers the client configured.

  • No existence leak

    Unauthorized resources are absent from listings and resolve as not found. The refusal is in the audit record, never in the response.

Statusauthorization in layersextensionsper-invocation admissiontool approval policies
deployment
SaaS tenant · or client infrastructure
where
a dedicated private tenant (SaaS), or the client's own infrastructure
durability
Temporal workers: checkpoint, suspend, resume; horizontal scaling
worker pools
separate pools for data fetching, file extraction, and the code interpreter
tenant
row-level security in Postgres · OpenFGA
models
a model per agent through provider adapters · client keys · no mid-run switching
training
client data is never used to train external models
residency
regions: TO CONFIRM
retention
data / content / telemetry: TO CONFIRM
Roadmapuser principal passed through to data platforms (Snowflake, Databricks row-level security)publication, provenance, and legal hold on resources

04Deployment and isolation

Deployed in the client's cloud. Client data never trains external models.

Pyrana is hosted as SaaS on a dedicated private tenant, or deployed into the client's own infrastructure for large enterprises. Temporal workers provide durability and horizontal scaling, with separate worker pools for data fetching, file extraction, and the code interpreter. Tenant isolation is enforced at the database with row-level security, with OpenFGA relationship checks above it.

A model is assigned per agent through provider adapters (Azure OpenAI, OpenAI, Anthropic, Fireworks, Google Gemini, and others), with the client's own keys; models are not switched mid-run. Knowledge lives in the context engine rather than in model weights.

Roadmap: passing the user's own principal through to data platforms such as Snowflake and Databricks, so their row-level security applies to the agent's query as it would to the person's.

05Audit and observability

Written before execution, not reconstructed from logs.

The gate claims an idempotency key and writes the execution row and the audit record in one transaction, before dispatch. A crash after dispatch leaves a record that says the call left the platform with an unknown outcome, never nothing. Every admitted call produces one AppExecution record, and a refused call leaves the same evidence as an admitted one. Traces, tokens, and tool errors for every run are captured and available as JSON.

AppExecution
exec_01J9Q4M7Z3 · completed
actor chain
maya.chen (sso) → finance-close@v14 → agent:close-reviewer → tool:ledger.journal.post
app
finance-close v14 · sha256:3f9a71c2…e08b
target
ledger.journal.post · lane=agent · door=copilot
profile / scope
controller · entity:US-01 · period:2026-08
resources
policy jrnl-threshold v3 · cxu_set close-controls 2026-08-30
policy
{ approval.journal.amount } · amount >= 25,000 USD → approval_required
approval
controller-approval · j.alvarez · approved · 2026-09-02T14:07:11Z
effects
erp.journal.create → JE-88213 · receipt sha256:b71d…
context
retrieved 12 ⊇ injected 6 ⊇ cited 2 · cxu:1220a7ff…f843 · cxu:9b31e0d4…21aa
ExportSIEM export path: TO CONFIRM

Illustrative record. Pyrana Capital is a synthetic portfolio.

06Compliance

Aligned means mapped, and to which criteria.

SOC 2 aligned means Pyrana's controls are mapped to the SOC 2 trust services criteria. Pyrana does not describe itself as certified until an auditor has. For customer programs under HIPAA, SOX, ISO 27001, and PCI DSS, the platform supplies the controls those programs need: identity, isolation, approval lanes, and an audit record written before execution.

SOC 2
Aligned. Controls mapped to the trust services criteria. Audit status: TO CONFIRM.
HIPAA · SOX · ISO 27001 · PCI DSS
Supports customer programs under these frameworks. Not a claim of certification.
Penetration testing
Firm and date: TO CONFIRM.
Subprocessors
List: TO CONFIRM.
Go deeperArchitecture and the waterline checklist4 min

07Responsible disclosure

Reporting a vulnerability

Security contact address and disclosure policy: TO CONFIRM before publication.

08Questions

Frequently asked

Where does Pyrana run?
Two ways: as SaaS on a dedicated private tenant, or deployed into the client's own infrastructure for large enterprises. Client data stays in the systems it already lives in and is reached live through tool sources; it is never used to train external models. Residency regions and additional deployment models: to be confirmed on this page.
How does the platform scale?
Temporal workers provide durability and horizontal scaling: every run checkpoints, suspends, and resumes. Separate worker pools handle data fetching, file extraction, and the code interpreter, so a heavy extraction job does not compete with an interactive session.
How is one tenant separated from another?
Row-level security in Postgres enforces tenant isolation at the database, with OpenFGA relationship checks above it. Every query carries the tenant; every call carries the actor chain.
What can an agent see that a person cannot?
Nothing. Agents pass the same gate and the same access layers as people: tenant, App membership, access profile, scope entitlement, approval lanes. A child call never exceeds its parent's authority. Unauthorized items are absent from results.
Does a user's own permission pass through to the data platforms?
All authorization is decided on the backend; nothing unauthorized reaches the frontend. Today, tool policies map a caller's scope entitlement to tool arguments before the call, so the tool holds the query and the agent passes only the entity and the period. Passing the user's own principal through to data platforms (Snowflake, Databricks row-level security) is on the roadmap.
What does the audit record contain?
The actor chain, the App version digest, the target and the door it arrived through, the profile and scope, the exact resource versions touched, the policy outcome and any approvals, the effects with receipts, and the context accounted as retrieved, injected, and cited. It is written in the same transaction as admission, before the call runs.
Can a security questionnaire be answered from this page?
Most of it. Items marked to confirm, and anything binding, are answered on request with mechanisms and documents.

Security questionnaires are answered with mechanisms.

Every control on this page maps to a step in the gate.

Contact usHow it works