Skip to main content

Application security

This page covers how untrusted models and third-party packages are constrained: signed platform → app calls, signed Marketplace packages, capability gates, and agent threat reduction.

App-builder contract: Developer security. Package rules: Solution security. Agent threat model: AI Agent Security.

Short definition (citation-ready)

Qefro authenticates platform invokes to /qefro with HMAC-SHA256 over timestamp and raw body, verifies Marketplace packages with Ed25519, rejects arbitrary JavaScript in solution packages, and mediates host capabilities on every call. Prompt injection is not “solved”; blast radius is limited with isolation, least-privilege tools, SSRF controls, and logs.

HMAC /qefro protocol

Platform → application calls (external SDK Connection and managed apps) use a shared signing secret:

payload = "v1:" + unix_timestamp + ":" + raw_request_body
signature = "v1=" + hex( HMAC_SHA256(signing_secret, payload) )

Headers: X-Qefro-Signature, X-Qefro-Timestamp, X-Qefro-Protocol. Default maximum timestamp skew is 300 seconds. Failed verification returns HTTP 401 invalid_signature.

The end user never holds this secret. Details: Authentication.

Tenancy headers and platform.* bindings are injected by Qefro. Applications must not trust client-supplied tenant ids over platform context.

Marketplace supply chain

ControlEnforcement
No arbitrary JavaScriptPackages are YAML, JSON, and images; script / js kinds rejected at publish
No iframe / DOM runtime in the packagePortal components render UI; no package-side browser VM
SigningEd25519 over id|version|checksum; registry verifies on store; installer re-verifies
ImmutabilityPublished versions do not change
Capability mediationDeclared at install; re-checked on every gated call
Catalog writesRestricted to platform admins (QEFRO_PLATFORM_ADMIN_IDS)

Business Tools vs SDK apps

PathTrustYour job
REST / OpenAPI toolQefro holds the service credential; model supplies argumentsValidate arguments on your API; least privilege; identify()
External /qefro appPrivileged peer — tool outputs are trusted by the assistantProtect the webhook URL; rotate HMAC secret; no SSRF from your outbound calls
Managed Marketplace appSame protocol; platform injects secrets and storage scopeLeast capabilities; no cross-tenant in-memory state

Treat the model as untrusted input to the tool layer in all three cases.

Prompt injection

No vendor can honestly claim to prevent all prompt injection. Qefro reduces impact by:

  • Workspace-scoped retrieval (hostile docs cannot search another workspace’s index)
  • Tool allowlists and auth levels (public / verified_channel / organization_challenge)
  • SSRF-blocked egress
  • Encrypted, non-prompt-resident secrets
  • Execution and identity logs

Assume uploaded documents and user messages are hostile when write tools are enabled.

Workflow

Ship an app without widening the blast radius

  1. Declare minimum capabilitiesInstall wizard shows tenants exactly what you asked for.
  2. Keep secrets out of the packagePackages are global and signed; no tenant URLs or keys in YAML.
  3. Validate tool argumentsSchema + server-side checks; never trust LLM JSON alone.
  4. Major-version permission changesAdding customer.read or new connectors is a breaking trust event.
  5. Review tool logs after installUnexpected invokes are incidents.

FAQ

Is tool permissions: string[] the same as Marketplace capabilities?
No. SDK tool permissions are advertised metadata (default empty). Install permission grants are enforced by the solution service. Do not confuse the two.
Can a Marketplace app run SQL on the platform database?
No. Solutions have no database or Redis handles. Persistence is ctx.storage and other mediated APIs only.
Should I use Ed25519 for /qefro signing?
No. /qefro uses a shared HMAC secret, not an Ed25519 keypair. Ed25519 is for Marketplace package signatures.