Security and privacy

Portal security posture today

The portal is static-first. It has no portal account or login system, no analytics or advertising cookies, no provider credentials or live provider calls, and no persistent support conversation. Examples use synthetic data. This describes the documentation portal; it does not mean a production integration should omit authentication.

Enrollment accepts only approved fields. After durable service acceptance, its confirmation state is short-lived, signed, HttpOnly, and opaque. It contains no personal data or package entitlement. Enrollment does not issue downloads, credentials, registry access, or package access.

Integration trust boundary

In an AnswerUp architecture, information from users, models, providers, callbacks, context snapshots, and serialized objects is untrusted until the host validates its structure, source, ownership, scope, and freshness. Do not enter secrets into the portal or public examples.

The responsibilities are divided as follows:

• The host authenticates callers, establishes requester and tenant scope, chooses authoritative systems, protects credentials, controls operator access, and owns retention and deletion.
• A provider adapter constrains provider-specific requests and responses, protects provider credentials, and keeps secrets out of public output.
• A verifier reads the intended authoritative record and rejects wrong-tenant, stale, malformed, contradictory, or foreign evidence.
• Core enforces bounded contracts, preserves separation, and fails closed. It cannot make an unsafe provider authoritative or repair untrusted host context.

Bounded inputs

Inputs must be limited in size and inspected without executing behavior hidden inside an object. Depending on the contract, that means byte, string, collection, and nesting bounds; strict UTF-8 and encoding rules; exact schemas; and rejection of dangerous keys, accessors, Proxies, cycles, and unsupported prototypes. Response bodies and errors are bounded too.

Privacy across the data path

Privacy follows the representation at each boundary:

proposal → trusted context → provider request → verifier evidence → private lifecycle record → bounded public claim

Each representation may contain different data. Public output generally needs far less than private provider or verifier records. Raw prompts, transcripts, customer records, provider payloads, credentials, unrestricted Trace, paths, stacks, and unrelated identifiers remain private or omitted. Omission is not evidence of absence. Public errors stay generic and bounded, and operator views remain access-controlled.

Credential-revocation example

Suppose a security administration UI calls an authenticated backend to revoke a compromised API credential. The host supplies the authenticated administrator, exact tenant scope, and an opaque credential reference. An identity or credential provider receives the constrained request; an independent verifier reads the authoritative credential directory; the application returns a bounded operator result.

The secret value never enters the proposal, Trace, ticket, or public result, and Core does not own or store it. A provider response saying “revoked” does not prove revocation. The verifier must read authoritative credential status. Unavailable or contradictory evidence produces bounded UNKNOWN. An operator ticket may include an opaque case reference, but not the secret or raw provider payload.

Enrollment and confirmation

The enrollment boundary uses streamed byte limits and strict parsing, accepts approved fields only, and rejects unknown and obsolete fields, including packageInterest. Durable provider acceptance remains separate from confirmation state. Confirmation cannot grant package access.

Operational responsibility and scope

This page documents design boundaries and integration responsibilities. Deployment controls, retention schedules, incident response, legal obligations, and regulatory assurance must be established and reviewed for the actual environment. The host owns authentication, tenant scope, credentials, external I/O, storage, monitoring, escalation, access, and deletion; the portal owns only its documented static and enrollment surface.