Skip to main contentPASS
Read the docs

Security model

What this architecture constrains, and what it does not

A permission layer narrows one class of risk: an actor doing something it was not permitted to do, for a party that never permitted it. It does not narrow the others.

Saying which class precisely, and naming what has to be trusted before even that claim holds, is the substance of a security model. The rest is assertion.

Where the check is placedRead the specification

01Trust assumptions

What must be true for a decision to mean anything

A permission decision is a claim about its inputs. Every input has an owner, and every owner is trusted for something specific. Naming them one at a time shows where a failure would land.

  1. The party granting the mandate

    A mandate is the definition of authority. PASS enforces what a mandate states, not what its author intended it to state.

    If this is wrongAuthority is enforced exactly as written, including where it was written more broadly than the situation called for.

  2. The issuer of a credential

    A credential is an assertion by an issuer that a subject meets a condition. Evaluation verifies that a valid attestation of a required type is held.

    If this is wrongAn issuer that attests without checking produces credentials that satisfy a mandate while the condition behind them is untrue.

  3. The adapter for a given protocol

    An adapter verifies the target, decodes the call, and derives the asset, action, venue and value that policy is evaluated against.

    If this is wrongA faulty decode produces a correct evaluation of wrong inputs. Approving an adapter is a security decision, not a configuration step.

  4. The price input for value limits

    A ceiling of $2,500 per transaction is a claim about value, and converting a token amount into a value requires a price.

    If this is wrongThe limit is wrong by whatever margin the price is wrong, and it is wrong in both directions.

  5. The enforcing implementation

    Every property described here belongs to a correct implementation of these rules, running where executions actually pass.

    If this is wrongA policy engine that evaluates incorrectly is more dangerous than none, because parties relying on it have stopped checking.

None of these assumptions is unusual; financial systems are built out of trusted parties with defined responsibilities. What is worth saying plainly is that a permission layer does not remove trust from the system. It moves trust to places where it can be named, scoped and withdrawn.

02Enforcement boundary

What PASS can enforce, and what it cannot

Both columns matter equally. A system that is vague about the second is asking to be trusted for work it does not do.

Enforced before capital moves

Evaluated against the governing mandate on every proposed execution.

  • Which actor may act, and for which subject.
  • Which assets are permitted, as an explicit allow set: AAPL and NVDA, and nothing merely adjacent to them.
  • Which actions are permitted, separately from assets. An actor may trade an asset while bridging it stays blocked.
  • Which venues are permitted, expressed as approved adapters rather than a self-declared destination.
  • The largest single movement: $2,500 per transaction.
  • Cumulative movement across a window: $10,000 of daily exposure.
  • Credential preconditions such as STOCK_TOKEN_ELIGIBLE, held and valid at the moment of evaluation.
  • Temporal validity. Expiry, suspension and revocation withdraw authority without touching the key.
  • Refusal of an execution that cannot be validated into policy inputs at all.

Outside what the check addresses

Real risks that a permission decision leaves exactly as it found them.

  • Market loss. A permitted trade in a permitted asset can lose money, and an authorization says nothing to the contrary.
  • Strategy quality. Evaluation decides whether an execution is permitted, never whether it is sensible.
  • A mandate written too broadly. Faithful enforcement of a wide grant is still a wide grant.
  • Smart contract defects at the target protocol. A permitted venue can still be a defective one.
  • Price correctness. Value limits inherit the accuracy of the input behind them.
  • Any path where the check can be skipped. A permission layer beside the execution path constrains only whoever calls it.

The first column narrows one class of risk to whatever the mandate states. The second lists classes of risk that are unchanged. A reader who takes the first as coverage of the second has been misled, and this page exists so that it does not happen quietly.

03Threat model

Scenarios, preserved properties, residual risk

Each row assumes the scenario has already happened. The middle column states what still holds and, where the scenario resolves into a refusal, names it. Rows without a refusal are the scenarios that produce none: the layer behaves correctly and the risk is untouched.

Threat scenarios, the property the architecture preserves in each, and the risk that remains afterwards.
ScenarioProperty preservedResidual risk
Compromised actor keyHolding a key confers no authority. Executions are still evaluated against the mandate, so an attacker inherits the permitted assets, actions, venues and limits rather than the account.BLOCKEDACTOR_NOT_AUTHORIZEDEverything the mandate permits stays available until it is suspended or revoked: $2,500 per transaction, $10,000 a day, in permitted assets. Noticing the compromise and withdrawing the mandate are separate problems.
Malicious or buggy executorAn executor cannot widen its own authority. A refusal stands regardless of what the executor believed it was doing.BLOCKEDACTION_NOT_ALLOWEDBad behaviour inside the permitted set remains possible: poor timing, unnecessary turnover, repeated transactions that each sit under the ceiling. Bounds constrain magnitude, not judgement.
Incorrect or malicious adapterOnly approved adapters produce intents, and venue permissions are enforced against the adapter rather than a declared destination.BLOCKEDADAPTER_NOT_ALLOWEDAn approved adapter that decodes incorrectly causes a correct evaluation of wrong inputs. Adapter correctness is trusted, and the approved set is part of the attack surface.
Expired, revoked or invalid credentialExpiry and revocation withdraw authority without any mandate being rewritten. An expired credential is treated as absent rather than as a warning.BLOCKEDCREDENTIAL_REVOKEDRevocation takes effect only as fast as revocation state can be observed at evaluation time, and a credential that is technically valid can still be wrong about the subject.
Compromised or careless issuerCredential requirements are stated by type and visible in the mandate. A requirement for STOCK_TOKEN_ELIGIBLE is not satisfied by an unrelated attestation.BLOCKEDMISSING_CREDENTIALEvaluation verifies attestation, not diligence. An issuer that attests carelessly produces credentials that pass. Issuer selection and revocation both sit outside the evaluation.
Manipulated or stale price dataValue limits are evaluated before submission against a stated input, so a breach is refused rather than found in a reconciliation afterwards.BLOCKEDTX_LIMIT_EXCEEDEDA $2,500 ceiling is exactly as accurate as the price behind it. Bad data breaks the limit in both directions: refusing permitted executions and admitting oversized ones.
Over-broad policy configurationWhat the mandate states is enforced consistently, and it is legible: a mandate can be read and argued with before anything relies on it.A mandate that permits too much is enforced faithfully. Nothing distinguishes a deliberate wide grant from a mistaken one. Reviewing what was granted remains a human control.
Administrative and governance controlThe power to grant, suspend and revoke is explicit, and every change is a change to a record rather than an informal capability spread through an application.Whoever can change policy can change what is permitted. How that power is held — key custody, timelocks, separation of duties — is a governance question the architecture does not answer on its own.
Integration placed where it can be bypassedWhere the check sits on the path an execution must take, an unevaluated execution does not reach the venue.Where it sits beside that path, it constrains only the callers that choose to use it. The property comes from placement, and placement is an integration decision made outside PASS.
Defects in PASS itselfThe evaluated surface is deliberately narrow: read the policy, evaluate the intent, return an outcome and a reason. The layer deciding what may happen does not hold the capital it governs.A defect in the enforcing implementation is a defect in the boundary. Non-custodial construction limits what can be removed directly; it does not make an incorrect authorization harmless. No audit is claimed.

04Trust boundaries

Three regions, read outward

What the layer decides, what it depends on being correct, and what it does not touch. Most disagreements about what a permission layer guarantees are disagreements about which region something belongs in.

  1. Decided by PASSEvaluated before capital moves
    • Actor bindingWhich actor acts for which subject
    • Permission setsAssets, actions, approved adapters
    • Value boundsPer transaction and per period
    • Credential preconditionsRequired types held and valid
    • Temporal validityExpiry, suspension, revocation
    • The decisionAn outcome and a reason code
  2. Depended uponCorrect only if these are correct
    • Mandate authorStates the authority enforced
    • Credential issuersAssert subject eligibility
    • AdaptersDecode a call into policy inputs
    • Price inputsDenominate value-based limits
    • Policy administrationGrants, suspends, revokes
    • The implementationEvaluates the rules correctly
  3. Outside the boundaryUnchanged by any decision
    • Target protocolsContract defects are unaffected
    • Market outcomeA permitted trade can still lose
    • Key custodyHow the actor holds its key
    • Actor reasoningWhy this execution was proposed
    • Unchecked pathsAnything reachable without the check

The middle region carries the weight. Everything asserted on the left is conditional on it, and nothing in either of the first two regions has any effect on the third.

05Failure behaviour

An execution that cannot be validated is refused

Refusal is the default outcome rather than an error path. When no adapter can derive an asset, an action, a venue and a value from a proposed call, there is nothing for policy to evaluate, and PASS returns a decision instead of a guess.

Proposed executionBLOCKEDINVALID_EXECUTION_CONTEXT
Actor
0x81…29F
Subject
0x3A…F02
Passport
0x7F…94A
Target
No approved adapter claims it
Asset
Undetermined
Action
Undetermined
Value
Undetermined
Decision
INVALID_EXECUTION_CONTEXT
Nothing here is a judgement about the transaction. It states that the inputs a policy decision requires could not be derived from it.

Failing closed is the correct bias here because the two directions of failure are not symmetric. Refusing a permitted execution costs time, and the execution can be proposed again. Admitting an execution that was never evaluated moves capital under an authority nobody checked, and it is discovered afterwards, if at all.

The cost of that bias belongs on this page. A missing adapter, an unavailable price input or an unreadable credential state stops permitted activity as firmly as a policy breach does. From where the actor stands, a refusal for want of inputs looks identical to a prohibition. Availability is a property of what surrounds PASS — adapter coverage, input freshness, operational care — and not something a decision procedure supplies on its own.

What a refusal always carries is a reason. A decision is an outcome paired with a stable identifier rather than a message, so an operational failure stays diagnosable and cannot be mistaken for a policy refusal.

Refusal reasons

Context
  • INVALID_EXECUTION_CONTEXT
Credential
  • MISSING_CREDENTIAL
  • CREDENTIAL_EXPIRED
  • CREDENTIAL_REVOKED
Permission
  • ASSET_NOT_ALLOWED
  • ACTION_NOT_ALLOWED
  • ADAPTER_NOT_ALLOWED
Limit
  • TX_LIMIT_EXCEEDED
  • DAILY_LIMIT_EXCEEDED
Lifecycle
  • MANDATE_EXPIRED
  • MANDATE_SUSPENDED
  • ACTOR_NOT_AUTHORIZED

06Responsible expectations

What is claimed, and what a claim is worth

  1. No audit is claimed. No third-party security review is claimed. Nothing here should be read as either.
  2. An architecture can be sound while an implementation of it is insecure. The first is settled by argument, the second only by reviewing code that runs.
  3. Every property stated here belongs to a correct implementation placed on the path an execution must take. Both conditions are load-bearing.
  4. A permission layer trusted beyond what it has shown is worse than none, because it changes how much authority a party delegates.
  5. The claims here are deliberately narrow. Narrow claims can be checked, and a claim that cannot be checked is not a security property.

Treat the threat model above as the interface: it is the list of things worth arguing with. A disagreement about a residual risk is a useful disagreement. An architecture that produced no such list would not be safer, only quieter about it.

07Continue

The security model in detail

The documentation carries what this page compresses: how a decision is produced and reported, how mandates and credentials are withdrawn, and why adapter correctness is the assumption most worth examining first.

Security modelAdapter architecture