FAQ

Services can authenticate an agent request without learning which organisation is accountable for the agent or seeing independent evidence about it. Trust Signals for Agentic Interactions (TSAI) is an open protocol for carrying that evidence in a verifiable credential. A trust authority evaluates an agent and its operator, then issues a short-lived credential containing identity, reputation, compliance, or assurance signals. The agent presents the credential and proves control of its bound key. The service provider verifies the presentation and applies its own policy.

Agent trust overlaps with authentication, authorisation, payments, and runtime security, so a clear boundary is necessary. TSAI defines the credential format, the meaning of its signals, the presentation and verification rules, and the trust authority lifecycle APIs. It carries evidence about the agent and accountable operator. It does not identify the user, grant delegated authority, create a payment mandate, inspect model execution, or guarantee future behaviour. Existing account, security, payment, and application controls retain those responsibilities; the adjacent standards section maps those boundaries.

Authentication gives a service limited verified context about the organisation and evidence behind an automated request. With TSAI, the agent can present signed evidence that identifies its persistent agent identity, accountable operator, and relevant trust signals. The common verification path uses prepared issuer keys and credential definitions, so it does not call the trust authority during the request. The service provider combines the evidence with its existing policy and traffic controls and can require a single-use challenge and exact request binding for a state-changing action.

Service providers may be concerned that a shared credential format transfers decision authority to the issuer. TSAI does not grant access or require acceptance of a credentialed agent. Each service provider chooses the trust authorities and signals it accepts and the controls appropriate to each action. A valid credential supplies evidence; it does not create an entitlement: TSAI signals; service providers decide.

A protocol for agent accountability should not require the user to manage another identity exchange during routine use. The user continues to direct the agent through the application or service they already use. The agent handles credential presentation, while the receiving service verifies it and applies policy. The TSAI credential contains no user identity or delegated authority, so account consent and payment approval remain in their existing flows. Whether the user sees an additional prompt therefore depends on those application controls, not on TSAI itself.

A credential is useful only when the recipient has reason to rely on its issuer and the operator can use it with relevant services. A trust authority publishes its evaluation criteria, reputation methodologies, signing-key metadata, signed operational report, and HSM attestation. Service providers assess that material together with the authority's legal identity, jurisdiction, security practices, availability, and incident history. Operators also consider which service providers accept the issuer and whether its methods suit their agents. Selection remains an ongoing trust decision rather than a consequence of protocol conformance alone.

Making every agent request depend on the issuing authority would add latency and create a central availability dependency. TSAI's common verification path uses a previously obtained issuer key, integrity-pinned credential definitions, and cached reputation methodologies. The credential remains independently verifiable during its 30-minute lifetime. A service provider may use a previously validated key in bounded degraded mode. Every cryptographic, identity, lifetime, and binding check still applies, and verification fails closed when the configured period ends. Online status remains a policy choice, while credentials from more than one accepted authority can provide additional continuity.

A trust authority is a high-value target because service providers rely on its signatures and evaluation. TSAI requires HSM-backed signing, restricted and auditable access, short-lived credentials, status publication, operational transparency, and an emergency key-rotation path independent of normal metadata availability. Service providers trust exact issuer identifiers and can remove an affected authority from their accepted set. Support for several authorities reduces dependence on one issuer. A compromised authority can issue false credentials under its own identity, but it cannot forge another authority's credentials, so governance and incident response remain necessary; the compromise-response guidance assigns the immediate actions.

Independent authorities may use different evidence and methodologies, so disagreement is normal and does not indicate a parsing error. An agent may present more than one credential, with each presentation bound to the same agent key. A service provider must not silently prefer one conflicting signal about the same operator. Its policy either resolves the conflict or treats the disputed signal as unresolved and does not rely on it. Reputation scores also remain authority-specific and require explicit calibration before comparison.

A valid signature establishes who issued evidence, but it does not make the underlying claim true. The trust authority is accountable for applying its stated process and issuing only what it established. The operator remains responsible for the information and systems it presents for evaluation. A named certifier, insurer, or backer remains subject to its separate legal and commercial arrangement because TSAI records attribution rather than its independent signature. The service provider remains responsible for deciding whether the evidence is sufficient for the action, while final liability depends on the applicable contracts and law.

An operator needs a practical way to question evidence that affects how services treat its agents. TSAI makes reputation methodology, interaction count, observation window, and confirmation time available so the basis of a signal can be examined. The current protocol does not define a universal appeal or dispute process between the operator and trust authority. Correction therefore follows the authority's published operational and contractual process, after which it can issue updated evidence or status as appropriate. Shared dispute requirements may develop through ecosystem governance, but they should not be presented as a current protocol guarantee.

Dependence on one authority could create commercial and operational lock-in. TSAI uses an open credential format and allows an agent to present credentials from more than one authority. An operator can enrol the same persistent agent identity with another authority and obtain a new credential under that authority's evaluation process. Service providers still accept only configured issuers, and evidence or reputation does not transfer automatically between methodologies. Changing authority is therefore possible without changing the protocol, but it still requires enrolment, evaluation, and acceptance by the relevant service providers.

Rotating a compromised or expired key should not erase the identity to which reputation, status, and policy apply. Every TSAI credential therefore carries a persistent HTTPS agent identifier in sub, while cnf holds the current binding key. The identifier lets service providers recognise the same agent after key rotation and lets a block remain attached to it. This continuity supports accountability and agent-level policy. It also enables correlation across service providers, so retention and cross-service sharing require deliberate privacy controls described in Security and privacy.

A service provider needs agent and operator accountability without routinely learning the identity of the person directing the agent. TSAI therefore excludes user identity, consent, and delegated authority from the credential. The common offline verification path also avoids telling the trust authority which service provider received a presentation. The persistent agent identifier remains correlatable, and an application may identify its user through separate account or payment systems where necessary. TSAI reduces unnecessary user disclosure, but it is not a general anonymity mechanism.

An open protocol should not reserve participation for large companies or proprietary agent platforms. In TSAI, an operator may be an organisation or an individual, provided a trust authority can establish the required legal identity, jurisdiction, verification depth, controlled domain, and binding key. The same identity floor and security requirements apply regardless of organisation size or software licence. Actual issuance availability, evaluation terms, and price depend on the trust authorities serving that market. The protocol therefore permits individual and open-source participation without creating an anonymous or lower-assurance credential class.

A short operating history provides less evidence, but absence of history is not evidence of poor behaviour. A TSAI reputation signal includes the interaction count, observation window, confirmation time, score, scope, and an integrity-pinned methodology. The methodology explains which interactions qualify and how insufficient history is treated. An operator-level reputation signal can provide additional context when the agent-level record is thin. The service provider decides whether identity, compliance, assurance, local observations, or restricted access are sufficient for the action.

Registering a new agent can leave an unfavourable agent-level record behind, but it does not remove the operator identity floor from the credential. A trust authority can also issue reputation scoped to the operator and aggregated across its agents. Service providers can combine agent-level and operator-level evidence with their own records. This limits reputation reset, although it does not eliminate every form of identity recreation or provide end-user uniqueness.

Services need to protect their systems, while agents need a clear way to present evidence without adopting a provider-specific identity scheme. TSAI keeps the specification and verification model open and gives agents a standard credential format. Each service provider publishes the issuers it accepts and retains control over its access policy. A valid credential does not compel acceptance, and an unidentified agent is not automatically malicious. The protocol therefore improves the evidence available to both sides, while competition, fairness, and legal access duties remain broader ecosystem concerns.

Professional trust authorities create a risk of concentration if credentials or verification depend on proprietary formats. TSAI uses an open credential format, public verification rules, and support for more than one accepted issuer. Operators choose which authorities evaluate them, while service providers choose which issuers and methodologies they trust. Authorities can differentiate through jurisdiction, expertise, methodology, service, and commercial terms without changing the base protocol. These properties reduce technical lock-in, although actual competition still depends on market access, governance, and viable operators.