{
  "schemaVersion": "1.0",
  "title": "Security model",
  "description": "Use this page to evaluate the security boundaries in the reviewed AIP implementation. It identifies protected assets, attacker capabilities, deployment assumptions, fail-closed decisions, component-compromise scope, and risks that remain af",
  "canonical": "https://getaip.org/docs/architecture/security-model",
  "route": "/docs/architecture/security-model",
  "source": "docs/architecture/security-model.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Architecture and Security",
  "documentType": "Architecture",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/architecture/security-model.md",
    "txt": "/docs/download/architecture/security-model.txt",
    "json": "/docs/download/architecture/security-model.json",
    "pdf": "/docs/download/architecture/security-model.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Security model\ndescription: Review AIP trust boundaries, fail-closed controls, compromise scope, and residual risk\nkind: explanation\naudience: security-reviewer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# Security model\n\nUse this page to evaluate the security boundaries in the reviewed AIP\nimplementation. It identifies protected assets, attacker capabilities,\ndeployment assumptions, fail-closed decisions, component-compromise scope, and\nrisks that remain after the implemented controls.\n\nThe page describes version `1.0.0` of the Rust workspace at source revision\n`97be86e9efedf07ecf1783b03800f683f107fb04`. It is a source-backed model, not\na penetration test, production certification, or assessment of one deployed\nenvironment.\n\n## Security objective\n\nThe implementation aims to ensure that only an authenticated and authorized\nprincipal can cause an action or read protected lifecycle state. The objective\nalso requires tenant, connector, credential, and provider-account selection to\ncome from trusted deployment state. Every external effect must remain\ncorrelated with durable intent and evidence.\n\nFive properties support that objective:\n\n| Property | Required security result |\n|---|---|\n| Authenticity and integrity | A receiving boundary verifies the immediate actor and rejects modified signed content |\n| Authorization and isolation | Capability, object, tenant, approval, route, and credential decisions use server-owned state |\n| Secret minimization | Raw credentials stay at the narrow invocation boundary and out of protocol records |\n| Replay and concurrency safety | Repeated messages, action intents, workers, replicas, and control operations are fenced at their own layer |\n| Audit and recovery | Durable records identify what was accepted, routed, attempted, decided, and left uncertain |\n\nThese properties do not make every envelope confidential. Native signatures\nprotect integrity and signer possession, while transport security or an\nexplicit session cipher must provide confidentiality where required.\n\n## Protect the assets that carry authority\n\n| Asset | Security significance |\n|---|---|\n| Signing and callback-encryption keys | Establish native peer identity or protect persisted Agent2Agent (A2A) push credentials |\n| Bearer tokens and provider credentials | Grant edge or external-product authority |\n| Trusted identity, tenant, and approval records | Convert caller claims into deployer-authorized context |\n| Capability and query policy | Decide which actor may execute or inspect which object |\n| Idempotency, replay, queue, and transaction state | Fence repeated intent and preserve uncertain work across failures |\n| Connector catalog, route assignments, leases, and credential revisions | Select one tenant-owned provider account and one admitted host |\n| Release packages and independent evidence | Decide which immutable connector artifact may enter the fleet |\n| Results, events, receipts, and audit records | Preserve operational, customer, and security-sensitive evidence |\n| Availability budgets and storage | Prevent one workload from silently consuming every execution or recovery path |\n\nIdentifiers, digests, opaque credential handles, and revision references are\nnot secret material by themselves. They still require integrity and access\ncontrol because changing one can redirect authority or corrupt evidence.\n\n## State the assumptions before evaluating controls\n\nThe source assumes that a deployment:\n\n- provisions the correct trusted decentralized identifier (DID), token issuer,\n  tenant, approval, release, and evidence-signer roots;\n- protects private keys, bearer tokens, database credentials, provider secrets,\n  and callback-encryption keys outside AIP payloads;\n- isolates the central daemon, registry administration, connector hosts, and\n  their operating-system identities according to the intended topology;\n- supplies a durable backend with the advertised single-process or shared\n  coordination guarantees;\n- terminates and authenticates network transports according to the selected\n  binding, including TLS and any proxy boundary;\n- maintains sufficiently accurate time for expiry, skew, lease, and replay\n  decisions;\n- controls DNS, certificates, network policy, and deployment configuration\n  around allowed remote destinations; and\n- treats connector and provider responses as untrusted data until their schema,\n  route, and product-specific checks pass.\n\nThe implementation validates many inputs to these assumptions, but it cannot\nprotect a private key disclosed by the secret store. It also cannot protect\nagainst a database administrator that can rewrite all state or a process running\nwith unrestricted host access.\n\n## Model an active untrusted caller\n\nThe model assumes an attacker may:\n\n- create arbitrary well-formed or malformed protocol payloads;\n- assert another principal, tenant, credential, account, callback, or\n  delegation in caller-controlled fields;\n- replay, reorder, delay, duplicate, or tamper with traffic;\n- guess object identifiers and query protected lifecycle endpoints;\n- disconnect or cause ambiguous responses around an external side effect;\n- send forged or repeated provider webhooks;\n- request callback or connector destinations that target internal networks;\n- induce concurrent workers, stale leases, retries, or old control messages;\n  and\n- publish an artifact or evidence document that should not pass admission.\n\nA valid credential or signed peer can also be malicious within its granted\nauthority. Authorization, tenant isolation, route binding, limits, and audit\ntherefore remain necessary after authentication.\n\n## Cross explicit trust boundaries\n\n~~~mermaid\nflowchart LR\n    U[\"Untrusted client or foreign protocol\"] --> E[\"Authenticated edge\"]\n    E --> G[\"Gateway trust and policy\"]\n    G --> R[\"Runtime lifecycle\"]\n    R --> C[\"Pinned connector route\"]\n    C --> H[\"Isolated connector host\"]\n    H --> P[\"External product\"]\n    H -->|signed events and callbacks| G\n    A[\"Release and evidence authorities\"] -.-> M[\"Admission boundary\"]\n    M -.-> C\n    S[\"Deployment secret and identity systems\"] -.-> E\n    S -.-> G\n    S -.-> H\n~~~\n\nThe text equivalent is:\n\n1. A native or compatibility edge authenticates the immediate caller before it\n   invokes a trusted gateway entrypoint.\n2. The gateway binds that actor to trusted identity and tenant state, claims\n   replay protection, and applies operational authorization.\n3. The runtime governs capability execution, approvals, idempotency,\n   transactions, lifecycle persistence, and recovery.\n4. Fleet work uses a durable route that pins one admitted connector version,\n   tenant instance, replica, peer identity, lease, and credential revision.\n5. The connector host verifies that route and central peer before resolving a\n   provider credential inside its process.\n6. Provider data, stream chunks, callbacks, and events return through their own\n   signature, route, replay, and schema checks.\n7. Separately trusted release and evidence authorities admit immutable\n   connector state; deployment systems supply identities and secrets without\n   becoming payload fields.\n\nTrust is local to each arrow. A signature, token, manifest, trust-domain label,\nroute, or approval at one boundary does not automatically authorize the next.\n\n## Bind native ingress to an expected principal\n\nThe default gateway requires a signed native envelope, a sender, and replay\nprotection. It canonicalizes the complete envelope and removes only\n`security.signature` from the signed representation. An application field\nalso named `signature` remains covered.\n\nEd25519 verification returns the `did:key` that possessed the signing key. The\ngateway then performs the separate trust decision: that DID must be explicitly\nbound to a server-owned principal, and `Envelope.from` must match its ID and\nkind. Key possession alone cannot choose a principal or tenant.\n\nAn already authenticated transport can instead call the matching trusted\nentrypoint. The gateway replaces the payload sender with the actor supplied by\nthat edge. This is safe only when the caller of that in-process API is itself a\ntrusted authentication boundary.\n\nThe daemon's native bearer comparison is constant-time and binds the accepted\ntoken to a configured principal. Unsigned native traffic without that\nauthenticated actor requires explicit insecure-development mode, which is\nrestricted to a loopback listener. A non-loopback configuration requires a\npublic HTTPS origin rather than treating plain public HTTP as secure.\n\nThe authentication-scheme enum also names OAuth2, mTLS, API-key, and webhook\nforms. Its existence does not prove that every listener implements every\nscheme. Review the selected edge, not the enum, for actual verification.\n\n## Separate authentication, authorization, and identity enrichment\n\nPayload `Principal`, `Envelope.from`, `Action.identity`, tenant,\ncredential, delegation, and trust-domain values are claims until a trusted\nboundary establishes them.\n\nThe gateway's identity resolver receives the authenticated actor and uses\ncaller values only as lookup hints. It rejects actor replacement, scope\nelevation, expired authentication or membership, tenant mismatch, an\nunacceptable credential issuer, missing required scopes, and conflicts between\nresolved identity and the verified tenant or credential handle. The runtime\ncopies only resolved identity over the action before persistence or execution.\n\nAuthorization remains layered:\n\n- capability policy checks principal kind, scope, delegation depth, risk, and\n  human-approval requirements;\n- approval authority verifies the approver independently of payload role text;\n- query policy checks authentication, object ownership or delegated authority,\n  tenant selection, operation-specific scope, and sensitive-field disclosure;\n  and\n- connector-host approval evidence is bound to the exact approval, action,\n  capability, decision, status, and tenant.\n\nKnowing an action, session, approval, transaction, receipt, or callback ID does\nnot grant read access. Authentication also does not grant provider-account\nselection.\n\nThe detailed identity objects and resolver flow are owned by\n[Identity and trust](../concepts/identity-and-trust.md).\n\n## Fence replay, repeated intent, and stale workers separately\n\nOne mechanism cannot solve every duplicate-delivery problem.\n\n| Mechanism | Rejects or fences | Important limit |\n|---|---|---|\n| Gateway replay claim | Reuse of a native message ID inside its accepted timestamp window | A new message ID can still describe the same action intent |\n| Webhook hash-based message authentication code (HMAC) and skew check | Forged payloads and deliveries outside the accepted time window | The receiving connector must also deduplicate the delivery ID |\n| Runtime idempotency reservation | Concurrent or repeated action intent bound to actor, capability, context, and input | It cannot make a non-idempotent provider atomic |\n| Queue and callback leases | Stale workers completing state owned by another attempt | Backend coordination must match the deployment's process count |\n| Route and replica fencing | A different or stale host acting for the pinned action | It does not determine provider truth after an ambiguous response |\n| Admission and lifecycle journals | Conflicting package revisions or stale host-control transitions | Administrator compromise remains outside application-level fencing |\n\nThe gateway checks message time and claims replay state before action dispatch.\nThe shared store must make that claim atomic across gateway instances.\n\nFor external mutations, the runtime can persist intent and provider-operation\ncheckpoints, while the connector can use a provider idempotency facility or\nreconciliation lookup. The code does not promise exactly-once provider effects.\n\n## Keep secrets behind opaque handles\n\nTrusted runtime context carries an opaque `CredentialHandle`, not token bytes.\nThe handle records an identifier, issuer, scopes, tenant partition, and expiry.\nA deployment-owned credential provider resolves it into short-lived\n`CredentialMaterial` only at connector invocation.\n\nThe material's debug output is redacted and its owned buffer is overwritten on\ndrop. Bearer-token wrappers follow the same redaction and clearing pattern.\nThis reduces accidental disclosure, but cannot erase copies made by HTTP\nlibraries, operating systems, crash dumps, or external providers.\n\n`ExecutionContext` is intentionally not serializable. Its redaction policy\ndenies common credential pointers and can mark all input or output sensitive.\nConnectors and observability code must still avoid placing raw payloads,\nauthorization headers, secrets, or unbounded provider errors into logs,\nevents, receipts, metrics, or stored actions.\n\nFor fleet work, the route contains an opaque credential revision, never the\nsecret. The host requires its handle and revision configuration to agree and\nconsults deployment-owned revision policy. Revocation fails the request even\nwhen an older action pinned that revision; an unavailable revision authority\nfails closed.\n\n## Constrain a connector host to one pinned route\n\nCentral route resolution uses verified tenant and capability context, not a\ncaller-selected endpoint or provider account. The durable assignment pins the\naction, capability, tenant, instance, replica, immutable version, manifest\ndigest, catalog and policy revisions, credential revision, quota reference,\npeer principal and DID, transport profile, capacity reservation, and fence.\n\nThe central dispatcher signs the action for the assigned host and validates the\nsigned response against the expected peer. The host independently verifies:\n\n- the native signature and configured central gateway DID and principal;\n- recipient and sender identity;\n- every route coordinate against its fixed instance and version;\n- active lease, health sequence, non-draining state, and local capacity;\n- verified tenant and provider-account mapping;\n- credential revision and any supplied approval authorization; and\n- capability, mode, schema, and admitted handler support before provider work.\n\nResponses are signed by the host. Stream callbacks and normalized provider\nevents traverse the reverse boundary: the central ingress checks the host DID,\nprincipal, trust domain, active replica, manifest or durable action route, and\nreplay state before accepting them.\n\nA compromised host is intended to be contained to its configured connector\ninstance, immutable version, provider credential, and signed host identity. It\ndoes not receive registry-administrator credentials and cannot self-admit a new\nrelease. Operating-system or network isolation must enforce that intended\ncontainment.\n\n## Require independent release evidence\n\nConnector admission is the only supported bridge from build evidence to\nmutable fleet catalog administration. A release authority signs one complete\npackage that binds the immutable artifact digest, manifest, implementation\nclaims, topology, instances, replicas, bindings, and evidence set.\n\nSeven evidence families are mandatory: artifact signature, software bill of\nmaterials, provenance, conformance, vulnerability policy, license policy, and\nrevocation observation. Each has a policy-specific trust-root set, exact\nartifact and manifest subjects, document digest, signed outcome, issue time,\nand hard expiry. The default policy also requires the package signer and all\nevidence signers to be distinct.\n\nAdmission derives registry attestation state after verification; a release\npayload cannot self-assert that its scans passed. Package size, evidence size,\ntopology counts, owner, clocks, versions, schema, and implementation support\nare bounded before catalog mutation.\n\nThis protects against artifact substitution and one broad release key asserting\nevery policy result. It does not prove that a trusted evaluator is correct or\nthat an admitted connector is harmless. Release and evidence root compromise,\nmalicious source accepted by every gate, and deployment-time image replacement\nremain supply-chain risks outside a signature check alone.\n\n## Restrict outbound destinations\n\nCallback and native remote clients apply destination policy before sending\ntrusted data. The reviewed HTTP callback policy starts with no allowed hosts,\ndisables plaintext HTTP, rejects private or non-public addresses, disables\nredirects, limits time and response size, and forbids URL user information and\nfragments.\n\nDNS is resolved under policy, and HTTP requests use the selected\npinned address. Private networks and plaintext HTTP require explicit\ncontrolled-deployment exceptions.\n\nExternal native callbacks require an Ed25519 signer. A2A push credentials can\nbe persisted only as AES-256-GCM ciphertext when the deployment supplies the\nshared encryption key required by every recovering replica. Callback payload\nsigning, destination authorization, credential encryption, and delivery state\nare separate controls.\n\nRemote connector HTTP policy can derive the host allowlist from the already\npinned registry endpoint while retaining scheme, address-range, timeout, body,\nsignature, and expected-peer checks. An endpoint present in caller payload does\nnot become an allowlist entry.\n\nThese controls reduce server-side request forgery and peer substitution. They\ndo not replace egress firewalls, service-mesh policy, certificate operations,\nDNS security, or segmentation.\n\n## Preserve durable coordination and bounded work\n\nReplay, idempotency, queue, callback, approval, transaction, and route safety\ndepend on atomic backend operations. In-memory state is process-local. The\nlocal file runtime is durable for one process, while the PostgreSQL runtime\nbundle advertises shared coordination and uses transactional leases and\ncompare-and-set transitions.\n\nRuntime callback and reconciliation work have independent concurrency budgets.\nRemote action scheduling has global and tenant bounds, and interfaces impose\nbounded timestamps, token sizes, response bodies, package documents, queue\nattempts, and retry windows at their respective boundaries.\n\nBounds reduce accidental or adversarial resource amplification. They are not a\ncomplete denial-of-service defense. Network admission control, rate limiting,\ndatabase capacity, tenant quotas, process limits, and upstream protection\nremain deployment responsibilities.\n\n## Interpret audit evidence accurately\n\nThe runtime records lifecycle events, results, approval and transaction state,\ncallback attempts, receipt chains, and recovery reports. Fleet state retains\nroute assignments, leases, settlements, admission operations, and signed\nrelease evidence.\n\nReceipt hashes and canonical digests can reveal changes within retained data.\nThey do not prevent an administrator from deleting an entire store, provide an\nexternal timestamp, or establish non-repudiation without an independently\nprotected signing and retention system.\n\nAudit access is itself authorized and may require a sensitive-field scope.\nRetention and redaction policy must balance investigation needs with customer\ndata and secret minimization.\n\n## Review component-compromise scope\n\n| Compromised component | Intended containment | Security consequence that remains |\n|---|---|---|\n| Untrusted client | Cannot establish a different signed or transport-bound actor | Can act within legitimately granted scopes and consume allowed capacity |\n| Trusted profile or authentication edge | Still faces gateway policy, tenant, runtime, and route checks | Can impersonate the actors that the gateway trusts it to establish |\n| Central daemon or its signing key | Product secrets remain in connector hosts and routes stay auditable | Can authorize, route, inspect central state, and send trusted host requests |\n| Registry reader path | Hosts still require signed central requests and exact fixed identity | Corrupted route state can misdirect central selection if the daemon accepts it |\n| Registry administrator or database | Host and release signatures provide partial independent evidence | Catalog, route, lease, or journal integrity can be subverted |\n| One connector host | No catalog administration and one intended instance or credential boundary | Can misuse its provider credential and emit messages as its trusted host identity |\n| Release package signer | Cannot alone create all distinct evidence outcomes | Can nominate malicious content and topology for the other authorities to evaluate |\n| One evidence authority | Other evidence kinds and package signature remain required | Can falsely approve the evidence family whose root it controls |\n| Provider account or API | AIP retains intent, route, and reconciliation evidence | Provider can return malicious data or commit effects contrary to expectations |\n| Complete deployment host or secret store | Application-level boundaries offer limited protection | Keys, processes, memory, databases, and provider credentials may all be exposed |\n\nThis table describes intended blast radius under the documented topology. It\ndoes not claim process isolation against software with unrestricted host or\ndatabase administrator access.\n\n## Residual-risk register\n\n| Residual risk | Required deployment or design response |\n|---|---|\n| Key or token compromise | Revoke and rotate the exact trust binding; investigate affected signed or authenticated work |\n| Incorrect identity, tenant, or approval authority | Treat resolver and authority configuration as security-critical reviewed code and data |\n| Database administrator compromise | Use database access control, encryption, backups, immutable external audit, and change monitoring |\n| Ambiguous provider mutation | Use provider idempotency and reconciliation; do not retry blindly or silently reroute |\n| Malicious connector or dependency | Preserve isolated hosts, least-privilege provider credentials, independent admission evidence, and egress policy |\n| Sensitive data in payloads or logs | Apply schema minimization, redaction, access control, retention, and incident review |\n| Resource exhaustion | Add edge rate limits, tenant quotas, storage capacity controls, and supervisor limits |\n| DNS, TLS, proxy, or network misconfiguration | Enforce deployment network policy and validate the effective route outside application source |\n| Lost or incomplete audit history | Export to independently protected retention where the threat model requires it |\n| Unsupported authentication assumption | Verify the concrete transport edge instead of relying on the `AuthScheme` vocabulary |\n\n## Security-review checklist\n\nBefore approving a deployment or change, answer:\n\n1. Which boundary authenticates the immediate caller, and which trusted gateway\n   entrypoint does it use?\n2. Which principal, tenant, scope, approval, and credential authority records\n   are trusted, revocable, and time-bounded?\n3. Which store durability class backs replay, idempotency, queue, callback,\n   transaction, and route state for the actual replica count?\n4. Which exact connector instance, peer DID, artifact digest, credential\n   revision, and lease can receive the action?\n5. Which provider operations are idempotent or reconcilable after an ambiguous\n   response?\n6. Which callback and connector destinations are allowlisted, address-checked,\n   TLS-protected, signed, and size-bounded?\n7. Where can raw credentials or sensitive payloads enter memory, logs, traces,\n   events, receipts, backups, or crash artifacts?\n8. Which release and evidence roots can admit an artifact, and how are they\n   rotated or revoked independently?\n9. What is the blast radius if the client edge, daemon, registry, one host, one\n   evidence signer, database, or secret store is compromised?\n10. Which claims have been verified in the deployed environment rather than\n    inferred from source support?\n\n## What this model does not guarantee\n\n- Signatures do not provide confidentiality, authorization, tenant membership,\n  key custody, or transitive trust.\n- A trust-domain label, manifest, ready process, or admitted artifact does not\n  authorize an action.\n- A static identity directory is not a universal IAM system.\n- Memory clearing cannot erase secret copies outside the owned buffer.\n- Leases, idempotency, and durable intent do not guarantee exactly-once\n  external effects.\n- Hash chains do not prevent record deletion or replace independently protected\n  audit storage.\n- Source support does not prove secure configuration, production enablement,\n  conformance, availability, or connector qualification.\n- This page does not assess any connector beyond Cal.diy, Hermes Agent,\n  Chatwoot, Dify, CrewAI, and Twenty.\n\n## Related pages\n\n- [Identity and trust](../concepts/identity-and-trust.md)\n- [Gateway](gateway.md)\n- [Runtime](runtime.md)\n- [Connector admission](connector-admission.md)\n- [Connector credentials and rotation](../guides/connector-credentials-and-rotation.md)\n",
    "text": "Security model\n\nUse this page to evaluate the security boundaries in the reviewed AIP\nimplementation. It identifies protected assets, attacker capabilities,\ndeployment assumptions, fail-closed decisions, component-compromise scope, and\nrisks that remain after the implemented controls.\n\nThe page describes version 1.0.0 of the Rust workspace at source revision\n97be86e9efedf07ecf1783b03800f683f107fb04. It is a source-backed model, not\na penetration test, production certification, or assessment of one deployed\nenvironment.\n\nSecurity objective\n\nThe implementation aims to ensure that only an authenticated and authorized\nprincipal can cause an action or read protected lifecycle state. The objective\nalso requires tenant, connector, credential, and provider-account selection to\ncome from trusted deployment state. Every external effect must remain\ncorrelated with durable intent and evidence.\n\nFive properties support that objective:\n\n| Property | Required security result |\n\n| Authenticity and integrity | A receiving boundary verifies the immediate actor and rejects modified signed content |\n| Authorization and isolation | Capability, object, tenant, approval, route, and credential decisions use server-owned state |\n| Secret minimization | Raw credentials stay at the narrow invocation boundary and out of protocol records |\n| Replay and concurrency safety | Repeated messages, action intents, workers, replicas, and control operations are fenced at their own layer |\n| Audit and recovery | Durable records identify what was accepted, routed, attempted, decided, and left uncertain |\n\nThese properties do not make every envelope confidential. Native signatures\nprotect integrity and signer possession, while transport security or an\nexplicit session cipher must provide confidentiality where required.\n\nProtect the assets that carry authority\n\n| Asset | Security significance |\n\n| Signing and callback-encryption keys | Establish native peer identity or protect persisted Agent2Agent (A2A) push credentials |\n| Bearer tokens and provider credentials | Grant edge or external-product authority |\n| Trusted identity, tenant, and approval records | Convert caller claims into deployer-authorized context |\n| Capability and query policy | Decide which actor may execute or inspect which object |\n| Idempotency, replay, queue, and transaction state | Fence repeated intent and preserve uncertain work across failures |\n| Connector catalog, route assignments, leases, and credential revisions | Select one tenant-owned provider account and one admitted host |\n| Release packages and independent evidence | Decide which immutable connector artifact may enter the fleet |\n| Results, events, receipts, and audit records | Preserve operational, customer, and security-sensitive evidence |\n| Availability budgets and storage | Prevent one workload from silently consuming every execution or recovery path |\n\nIdentifiers, digests, opaque credential handles, and revision references are\nnot secret material by themselves. They still require integrity and access\ncontrol because changing one can redirect authority or corrupt evidence.\n\nState the assumptions before evaluating controls\n\nThe source assumes that a deployment:\n• provisions the correct trusted decentralized identifier (DID), token issuer,\n  tenant, approval, release, and evidence-signer roots;\n• protects private keys, bearer tokens, database credentials, provider secrets,\n  and callback-encryption keys outside AIP payloads;\n• isolates the central daemon, registry administration, connector hosts, and\n  their operating-system identities according to the intended topology;\n• supplies a durable backend with the advertised single-process or shared\n  coordination guarantees;\n• terminates and authenticates network transports according to the selected\n  binding, including TLS and any proxy boundary;\n• maintains sufficiently accurate time for expiry, skew, lease, and replay\n  decisions;\n• controls DNS, certificates, network policy, and deployment configuration\n  around allowed remote destinations; and\n• treats connector and provider responses as untrusted data until their schema,\n  route, and product-specific checks pass.\n\nThe implementation validates many inputs to these assumptions, but it cannot\nprotect a private key disclosed by the secret store. It also cannot protect\nagainst a database administrator that can rewrite all state or a process running\nwith unrestricted host access.\n\nModel an active untrusted caller\n\nThe model assumes an attacker may:\n• create arbitrary well-formed or malformed protocol payloads;\n• assert another principal, tenant, credential, account, callback, or\n  delegation in caller-controlled fields;\n• replay, reorder, delay, duplicate, or tamper with traffic;\n• guess object identifiers and query protected lifecycle endpoints;\n• disconnect or cause ambiguous responses around an external side effect;\n• send forged or repeated provider webhooks;\n• request callback or connector destinations that target internal networks;\n• induce concurrent workers, stale leases, retries, or old control messages;\n  and\n• publish an artifact or evidence document that should not pass admission.\n\nA valid credential or signed peer can also be malicious within its granted\nauthority. Authorization, tenant isolation, route binding, limits, and audit\ntherefore remain necessary after authentication.\n\nCross explicit trust boundaries\n\nmermaid\nflowchart LR\n    U[\"Untrusted client or foreign protocol\"] --> E[\"Authenticated edge\"]\n    E --> G[\"Gateway trust and policy\"]\n    G --> R[\"Runtime lifecycle\"]\n    R --> C[\"Pinned connector route\"]\n    C --> H[\"Isolated connector host\"]\n    H --> P[\"External product\"]\n    H -->|signed events and callbacks| G\n    A[\"Release and evidence authorities\"] -.-> M[\"Admission boundary\"]\n    M -.-> C\n    S[\"Deployment secret and identity systems\"] -.-> E\n    S -.-> G\n    S -.-> H\n\nThe text equivalent is:\n1. A native or compatibility edge authenticates the immediate caller before it\n   invokes a trusted gateway entrypoint.\n2. The gateway binds that actor to trusted identity and tenant state, claims\n   replay protection, and applies operational authorization.\n3. The runtime governs capability execution, approvals, idempotency,\n   transactions, lifecycle persistence, and recovery.\n4. Fleet work uses a durable route that pins one admitted connector version,\n   tenant instance, replica, peer identity, lease, and credential revision.\n5. The connector host verifies that route and central peer before resolving a\n   provider credential inside its process.\n6. Provider data, stream chunks, callbacks, and events return through their own\n   signature, route, replay, and schema checks.\n7. Separately trusted release and evidence authorities admit immutable\n   connector state; deployment systems supply identities and secrets without\n   becoming payload fields.\n\nTrust is local to each arrow. A signature, token, manifest, trust-domain label,\nroute, or approval at one boundary does not automatically authorize the next.\n\nBind native ingress to an expected principal\n\nThe default gateway requires a signed native envelope, a sender, and replay\nprotection. It canonicalizes the complete envelope and removes only\nsecurity.signature from the signed representation. An application field\nalso named signature remains covered.\n\nEd25519 verification returns the did:key that possessed the signing key. The\ngateway then performs the separate trust decision: that DID must be explicitly\nbound to a server-owned principal, and Envelope.from must match its ID and\nkind. Key possession alone cannot choose a principal or tenant.\n\nAn already authenticated transport can instead call the matching trusted\nentrypoint. The gateway replaces the payload sender with the actor supplied by\nthat edge. This is safe only when the caller of that in-process API is itself a\ntrusted authentication boundary.\n\nThe daemon's native bearer comparison is constant-time and binds the accepted\ntoken to a configured principal. Unsigned native traffic without that\nauthenticated actor requires explicit insecure-development mode, which is\nrestricted to a loopback listener. A non-loopback configuration requires a\npublic HTTPS origin rather than treating plain public HTTP as secure.\n\nThe authentication-scheme enum also names OAuth2, mTLS, API-key, and webhook\nforms. Its existence does not prove that every listener implements every\nscheme. Review the selected edge, not the enum, for actual verification.\n\nSeparate authentication, authorization, and identity enrichment\n\nPayload Principal, Envelope.from, Action.identity, tenant,\ncredential, delegation, and trust-domain values are claims until a trusted\nboundary establishes them.\n\nThe gateway's identity resolver receives the authenticated actor and uses\ncaller values only as lookup hints. It rejects actor replacement, scope\nelevation, expired authentication or membership, tenant mismatch, an\nunacceptable credential issuer, missing required scopes, and conflicts between\nresolved identity and the verified tenant or credential handle. The runtime\ncopies only resolved identity over the action before persistence or execution.\n\nAuthorization remains layered:\n• capability policy checks principal kind, scope, delegation depth, risk, and\n  human-approval requirements;\n• approval authority verifies the approver independently of payload role text;\n• query policy checks authentication, object ownership or delegated authority,\n  tenant selection, operation-specific scope, and sensitive-field disclosure;\n  and\n• connector-host approval evidence is bound to the exact approval, action,\n  capability, decision, status, and tenant.\n\nKnowing an action, session, approval, transaction, receipt, or callback ID does\nnot grant read access. Authentication also does not grant provider-account\nselection.\n\nThe detailed identity objects and resolver flow are owned by\nIdentity and trust (../concepts/identity-and-trust.md).\n\nFence replay, repeated intent, and stale workers separately\n\nOne mechanism cannot solve every duplicate-delivery problem.\n\n| Mechanism | Rejects or fences | Important limit |\n\n| Gateway replay claim | Reuse of a native message ID inside its accepted timestamp window | A new message ID can still describe the same action intent |\n| Webhook hash-based message authentication code (HMAC) and skew check | Forged payloads and deliveries outside the accepted time window | The receiving connector must also deduplicate the delivery ID |\n| Runtime idempotency reservation | Concurrent or repeated action intent bound to actor, capability, context, and input | It cannot make a non-idempotent provider atomic |\n| Queue and callback leases | Stale workers completing state owned by another attempt | Backend coordination must match the deployment's process count |\n| Route and replica fencing | A different or stale host acting for the pinned action | It does not determine provider truth after an ambiguous response |\n| Admission and lifecycle journals | Conflicting package revisions or stale host-control transitions | Administrator compromise remains outside application-level fencing |\n\nThe gateway checks message time and claims replay state before action dispatch.\nThe shared store must make that claim atomic across gateway instances.\n\nFor external mutations, the runtime can persist intent and provider-operation\ncheckpoints, while the connector can use a provider idempotency facility or\nreconciliation lookup. The code does not promise exactly-once provider effects.\n\nKeep secrets behind opaque handles\n\nTrusted runtime context carries an opaque CredentialHandle, not token bytes.\nThe handle records an identifier, issuer, scopes, tenant partition, and expiry.\nA deployment-owned credential provider resolves it into short-lived\nCredentialMaterial only at connector invocation.\n\nThe material's debug output is redacted and its owned buffer is overwritten on\ndrop. Bearer-token wrappers follow the same redaction and clearing pattern.\nThis reduces accidental disclosure, but cannot erase copies made by HTTP\nlibraries, operating systems, crash dumps, or external providers.\n\nExecutionContext is intentionally not serializable. Its redaction policy\ndenies common credential pointers and can mark all input or output sensitive.\nConnectors and observability code must still avoid placing raw payloads,\nauthorization headers, secrets, or unbounded provider errors into logs,\nevents, receipts, metrics, or stored actions.\n\nFor fleet work, the route contains an opaque credential revision, never the\nsecret. The host requires its handle and revision configuration to agree and\nconsults deployment-owned revision policy. Revocation fails the request even\nwhen an older action pinned that revision; an unavailable revision authority\nfails closed.\n\nConstrain a connector host to one pinned route\n\nCentral route resolution uses verified tenant and capability context, not a\ncaller-selected endpoint or provider account. The durable assignment pins the\naction, capability, tenant, instance, replica, immutable version, manifest\ndigest, catalog and policy revisions, credential revision, quota reference,\npeer principal and DID, transport profile, capacity reservation, and fence.\n\nThe central dispatcher signs the action for the assigned host and validates the\nsigned response against the expected peer. The host independently verifies:\n• the native signature and configured central gateway DID and principal;\n• recipient and sender identity;\n• every route coordinate against its fixed instance and version;\n• active lease, health sequence, non-draining state, and local capacity;\n• verified tenant and provider-account mapping;\n• credential revision and any supplied approval authorization; and\n• capability, mode, schema, and admitted handler support before provider work.\n\nResponses are signed by the host. Stream callbacks and normalized provider\nevents traverse the reverse boundary: the central ingress checks the host DID,\nprincipal, trust domain, active replica, manifest or durable action route, and\nreplay state before accepting them.\n\nA compromised host is intended to be contained to its configured connector\ninstance, immutable version, provider credential, and signed host identity. It\ndoes not receive registry-administrator credentials and cannot self-admit a new\nrelease. Operating-system or network isolation must enforce that intended\ncontainment.\n\nRequire independent release evidence\n\nConnector admission is the only supported bridge from build evidence to\nmutable fleet catalog administration. A release authority signs one complete\npackage that binds the immutable artifact digest, manifest, implementation\nclaims, topology, instances, replicas, bindings, and evidence set.\n\nSeven evidence families are mandatory: artifact signature, software bill of\nmaterials, provenance, conformance, vulnerability policy, license policy, and\nrevocation observation. Each has a policy-specific trust-root set, exact\nartifact and manifest subjects, document digest, signed outcome, issue time,\nand hard expiry. The default policy also requires the package signer and all\nevidence signers to be distinct.\n\nAdmission derives registry attestation state after verification; a release\npayload cannot self-assert that its scans passed. Package size, evidence size,\ntopology counts, owner, clocks, versions, schema, and implementation support\nare bounded before catalog mutation.\n\nThis protects against artifact substitution and one broad release key asserting\nevery policy result. It does not prove that a trusted evaluator is correct or\nthat an admitted connector is harmless. Release and evidence root compromise,\nmalicious source accepted by every gate, and deployment-time image replacement\nremain supply-chain risks outside a signature check alone.\n\nRestrict outbound destinations\n\nCallback and native remote clients apply destination policy before sending\ntrusted data. The reviewed HTTP callback policy starts with no allowed hosts,\ndisables plaintext HTTP, rejects private or non-public addresses, disables\nredirects, limits time and response size, and forbids URL user information and\nfragments.\n\nDNS is resolved under policy, and HTTP requests use the selected\npinned address. Private networks and plaintext HTTP require explicit\ncontrolled-deployment exceptions.\n\nExternal native callbacks require an Ed25519 signer. A2A push credentials can\nbe persisted only as AES-256-GCM ciphertext when the deployment supplies the\nshared encryption key required by every recovering replica. Callback payload\nsigning, destination authorization, credential encryption, and delivery state\nare separate controls.\n\nRemote connector HTTP policy can derive the host allowlist from the already\npinned registry endpoint while retaining scheme, address-range, timeout, body,\nsignature, and expected-peer checks. An endpoint present in caller payload does\nnot become an allowlist entry.\n\nThese controls reduce server-side request forgery and peer substitution. They\ndo not replace egress firewalls, service-mesh policy, certificate operations,\nDNS security, or segmentation.\n\nPreserve durable coordination and bounded work\n\nReplay, idempotency, queue, callback, approval, transaction, and route safety\ndepend on atomic backend operations. In-memory state is process-local. The\nlocal file runtime is durable for one process, while the PostgreSQL runtime\nbundle advertises shared coordination and uses transactional leases and\ncompare-and-set transitions.\n\nRuntime callback and reconciliation work have independent concurrency budgets.\nRemote action scheduling has global and tenant bounds, and interfaces impose\nbounded timestamps, token sizes, response bodies, package documents, queue\nattempts, and retry windows at their respective boundaries.\n\nBounds reduce accidental or adversarial resource amplification. They are not a\ncomplete denial-of-service defense. Network admission control, rate limiting,\ndatabase capacity, tenant quotas, process limits, and upstream protection\nremain deployment responsibilities.\n\nInterpret audit evidence accurately\n\nThe runtime records lifecycle events, results, approval and transaction state,\ncallback attempts, receipt chains, and recovery reports. Fleet state retains\nroute assignments, leases, settlements, admission operations, and signed\nrelease evidence.\n\nReceipt hashes and canonical digests can reveal changes within retained data.\nThey do not prevent an administrator from deleting an entire store, provide an\nexternal timestamp, or establish non-repudiation without an independently\nprotected signing and retention system.\n\nAudit access is itself authorized and may require a sensitive-field scope.\nRetention and redaction policy must balance investigation needs with customer\ndata and secret minimization.\n\nReview component-compromise scope\n\n| Compromised component | Intended containment | Security consequence that remains |\n\n| Untrusted client | Cannot establish a different signed or transport-bound actor | Can act within legitimately granted scopes and consume allowed capacity |\n| Trusted profile or authentication edge | Still faces gateway policy, tenant, runtime, and route checks | Can impersonate the actors that the gateway trusts it to establish |\n| Central daemon or its signing key | Product secrets remain in connector hosts and routes stay auditable | Can authorize, route, inspect central state, and send trusted host requests |\n| Registry reader path | Hosts still require signed central requests and exact fixed identity | Corrupted route state can misdirect central selection if the daemon accepts it |\n| Registry administrator or database | Host and release signatures provide partial independent evidence | Catalog, route, lease, or journal integrity can be subverted |\n| One connector host | No catalog administration and one intended instance or credential boundary | Can misuse its provider credential and emit messages as its trusted host identity |\n| Release package signer | Cannot alone create all distinct evidence outcomes | Can nominate malicious content and topology for the other authorities to evaluate |\n| One evidence authority | Other evidence kinds and package signature remain required | Can falsely approve the evidence family whose root it controls |\n| Provider account or API | AIP retains intent, route, and reconciliation evidence | Provider can return malicious data or commit effects contrary to expectations |\n| Complete deployment host or secret store | Application-level boundaries offer limited protection | Keys, processes, memory, databases, and provider credentials may all be exposed |\n\nThis table describes intended blast radius under the documented topology. It\ndoes not claim process isolation against software with unrestricted host or\ndatabase administrator access.\n\nResidual-risk register\n\n| Residual risk | Required deployment or design response |\n\n| Key or token compromise | Revoke and rotate the exact trust binding; investigate affected signed or authenticated work |\n| Incorrect identity, tenant, or approval authority | Treat resolver and authority configuration as security-critical reviewed code and data |\n| Database administrator compromise | Use database access control, encryption, backups, immutable external audit, and change monitoring |\n| Ambiguous provider mutation | Use provider idempotency and reconciliation; do not retry blindly or silently reroute |\n| Malicious connector or dependency | Preserve isolated hosts, least-privilege provider credentials, independent admission evidence, and egress policy |\n| Sensitive data in payloads or logs | Apply schema minimization, redaction, access control, retention, and incident review |\n| Resource exhaustion | Add edge rate limits, tenant quotas, storage capacity controls, and supervisor limits |\n| DNS, TLS, proxy, or network misconfiguration | Enforce deployment network policy and validate the effective route outside application source |\n| Lost or incomplete audit history | Export to independently protected retention where the threat model requires it |\n| Unsupported authentication assumption | Verify the concrete transport edge instead of relying on the AuthScheme vocabulary |\n\nSecurity-review checklist\n\nBefore approving a deployment or change, answer:\n1. Which boundary authenticates the immediate caller, and which trusted gateway\n   entrypoint does it use?\n2. Which principal, tenant, scope, approval, and credential authority records\n   are trusted, revocable, and time-bounded?\n3. Which store durability class backs replay, idempotency, queue, callback,\n   transaction, and route state for the actual replica count?\n4. Which exact connector instance, peer DID, artifact digest, credential\n   revision, and lease can receive the action?\n5. Which provider operations are idempotent or reconcilable after an ambiguous\n   response?\n6. Which callback and connector destinations are allowlisted, address-checked,\n   TLS-protected, signed, and size-bounded?\n7. Where can raw credentials or sensitive payloads enter memory, logs, traces,\n   events, receipts, backups, or crash artifacts?\n8. Which release and evidence roots can admit an artifact, and how are they\n   rotated or revoked independently?\n9. What is the blast radius if the client edge, daemon, registry, one host, one\n   evidence signer, database, or secret store is compromised?\n10. Which claims have been verified in the deployed environment rather than\n    inferred from source support?\n\nWhat this model does not guarantee\n• Signatures do not provide confidentiality, authorization, tenant membership,\n  key custody, or transitive trust.\n• A trust-domain label, manifest, ready process, or admitted artifact does not\n  authorize an action.\n• A static identity directory is not a universal IAM system.\n• Memory clearing cannot erase secret copies outside the owned buffer.\n• Leases, idempotency, and durable intent do not guarantee exactly-once\n  external effects.\n• Hash chains do not prevent record deletion or replace independently protected\n  audit storage.\n• Source support does not prove secure configuration, production enablement,\n  conformance, availability, or connector qualification.\n• This page does not assess any connector beyond Cal.diy, Hermes Agent,\n  Chatwoot, Dify, CrewAI, and Twenty.\n\nRelated pages\n• Identity and trust (../concepts/identity-and-trust.md)\n• Gateway (gateway.md)\n• Runtime (runtime.md)\n• Connector admission (connector-admission.md)\n• Connector credentials and rotation (../guides/connector-credentials-and-rotation.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "9766b7bb3bf91a95dfe04a288caa88006222fcfe7ba030b53ae28361451c8d6a"
  }
}