Trusted context

Trusted context is information the application establishes from sources it trusts before Core evaluates a consequential action. It tells Core who is acting, which account or tenant is involved, where relevant facts came from, and how current those facts are. A proposal is not permission or proof.

What the application supplies

In an existing architecture, the host might combine an authenticated session from its identity system, account scope from its backend, a bounded record from a CRM or database, and a policy or snapshot revision. Core receives that bounded context from the host. It does not authenticate the user, query the database, or decide which external system is authoritative.

For each important fact, ask once:

• Who or what supplied it?
• Which account, tenant, or operation does it apply to?
• How current is it?

The host should carry the source and revision with the context and keep the scope exact. A user or model assertion cannot create trusted context or override the identity, tenant, or snapshot supplied by the host.

Reserved proposal fields in Actions preview.8

@answerup/actions@0.2.0-preview.8 rejects proposal objects containing any of these exact, case-sensitive property names, including nested objects and objects in arrays:

tenant, tenantRef, securityDomain, securityDomainRef, actor, actorRef, assurance, authorization, scope, scopeRef, provider, providerAccount, credentials, policyRevision, authoritativeState, stateRevision.

This guard separates proposal data from host-owned authority. It checks the original run({ input, context }) proposal after validateProposal returns valid, before trusted-context admission to Runtime, grounding, authorization or dispatch. Removing a reserved field only from the validator's returned input does not avoid the check. inputSchema is metadata, not executable validation. The declared strictAuthorityFields option does not disable this guard in preview.8.

For this rejection, preview.8 returns kind: "INVALID_PROPOSAL", reason: "INVALID_PROPOSAL", effectTruth.status: "NOT_DISPATCHED" and providerDispatchOccurred: false. Other invalid proposals use the same reason; this result alone does not identify a reserved field. Check your submitted field names against the list without logging payload values or credentials.

When adapting an existing application, explicitly select business fields for the proposal before calling run. For example, map an existing inventory record's tenant field to a business field named warehouse, then map it back only when invoking the existing business function. Update both your executable validator and schema metadata to describe warehouse. Moving tenant into a nested object still triggers the guard.

The renamed business field remains untrusted. Continue deriving context.tenant, actor, policy and provider context from authenticated host sources, and use your authorization policy to check that the requested warehouse belongs to that trusted scope. Do not copy proposal values into TrustedContext, disable validation, silently drop a business constraint or use renaming to grant authority. The explicit mapping is application integration code; it does not change SDK admission or business authorization.

Why source and freshness matter

Context is admitted before grounding and authorization. It gives those stages a stable identity, scope, and snapshot to use. It also gives later verification the binding needed to interpret evidence. A stale or foreign record can look plausible while referring to the wrong account or an earlier policy state.

Missing, malformed, overlarge, foreign, contradictory, or stale context fails closed. Depending on the lifecycle point, the host may refresh it, request clarification, or expose an unresolved result; it must not silently repair or broaden the context. Trusted authorization context still does not prove an external effect.

Example: changing a company billing contact

A support application receives a request to change the billing contact for a company account. The request could come from a web UI, support copilot, or API workflow. Its backend supplies the authenticated staff identity, company account, CRM record revision, and applicable policy context.

The application can then ground the request and authorize that exact account and change. A model-generated claim that the requester is an administrator cannot override the host-supplied identity or tenant. If the CRM revision is stale or belongs to another account, the host refreshes or fails closed before dispatch.

Responsibilities

The host owns authentication, tenant isolation, context acquisition, freshness policy, credentials, privacy, and the choice of authoritative sources. Core supplies bounded lifecycle classification and safe claim projection for the context it receives. Neither trusted context nor a provider acknowledgment establishes that the billing contact was actually changed; an independent authoritative read is needed for effect truth.