Trust Profiles Need a Lifecycle, Not Just a Snapshot

This article extends “Trust Profiles Are Useful Only When They Change the Next Action” with a concrete lifecycle for building, checking, expiring, and renewing trust decisions in agent workflows.

Start with an evidence-backed proposal

A profile should enter a workflow as a proposal, not as an authorization. At this stage, the agent or coordinator gathers the facts needed for a bounded decision:

Who or what is the subject?
Which task, resource, and time window are in scope?
Which capabilities are claimed?
What evidence supports each claim?
What transition is being requested?

This distinction prevents a common shortcut: copying an identity description into a permission decision. A profile can state that an agent has a browser tool, for example, without implying that it may purchase a ticket or submit a form.

The proposal should also name its assumptions. If a result depends on a current policy, an unexpired credential, a particular recipient, or a specific input file, record that dependency. Assumptions are what make later re-checks possible.

Check the profile at the boundary that consumes it

Verification is not one universal event. It is a decision made at a workflow boundary. A profile used to authorize reading data may need a different check from one used before an external write.

A useful boundary record can include:

1. Requested transition — the exact step the workflow wants to take.
2. Relevant claims — only the profile attributes needed for that transition.
3. Evidence status — verified, missing, stale, or contradicted.
4. Disposition — proceed, prepare for review, or stop.
5. Re-check condition — what change invalidates this decision.

This keeps verification proportional. There is no reason to re-audit every historical attribute when only the recipient or output scope changed. Conversely, a prior successful check should not be reused blindly when the action has become externally visible.

Expiration is a safety feature

A profile without an expiration condition quietly becomes reputation. That is dangerous because agent work changes faster than static descriptions suggest. Credentials expire, policies change, data sources move, and an apparently harmless draft can acquire a new audience.

Expiration does not have to mean a short clock for every task. It can be event-based:

the input set changes;
the requested action changes;
the policy version changes;
the evidence source is withdrawn;
the recipient, destination, or blast radius changes;
a human approval no longer matches the artifact.

When one of these events occurs, the safe default is not to erase the work. Keep the artifact, mark the decision stale, and route it back to the smallest required checkpoint. This preserves progress without allowing an old decision to authorize a new effect.

Renewal should preserve the evidence trail

Renewal is not a fresh profile copied from the old one. It is a new decision that may reuse still-valid evidence and must identify what was checked again.

A compact renewal record might say:

``text profile: travel-research-agent scope: itinerary draft, no purchase previous_decision: review-required rechecked: source freshness, destination constraints unchanged: draft-only permission new_condition: booking requires principal approval result: renewed for itinerary preparation until next input change ``

The important property is continuity. A reviewer can see what carried forward, what changed, and why the scope remains bounded. If the evidence is missing, renewal should produce a visible stop condition rather than a more optimistic label.

Use the lifecycle to control handoffs

Trust decisions become especially fragile when work moves between agents. The receiving agent should not inherit authority merely because the sending agent completed its step. The handoff needs its own profile interpretation.

For each handoff, pass three things together:

the artifact or commitment being transferred;
the evidence paths supporting its claims;
the receiving agent’s allowed next transition.

Suppose one agent researches flight options and another prepares an itinerary. The second agent may rely on the research as input, but it should not infer permission to book. If the itinerary is later sent to a travel provider, that is a new transition with a new review condition.

This design makes the system drainable. Completed work can move forward predictably, while commitments with unresolved authority remain visible in a queue instead of becoming ambient side effects.

A practical implementation for builders

Start small. Store one profile beside one workflow artifact, using markdown or JSON. Include:

subject and scope;
requested_transition;
evidence paths;
allowed and blocked transitions;
status: proposed, verified, stale, approved, or stopped;
expires_on or event-based invalidation rules;
checked_at and the next required checkpoint.

Then test four changes: alter an input, change the destination, let evidence expire, and replace the requested transition with a more consequential one. Each test should either preserve the decision for a documented reason or return the work to review.

Do not use a trust profile to bypass transport or publication gates. Its job is to make the decision legible and bounded. Policy still decides whether an external action is allowed; execution still happens only after the required approval.

Conclusion: renew the promise when the world changes

A trust profile should have a beginning, a verification point, an expiration rule, and a renewal path. That lifecycle is more useful than a permanent score because it reflects the conditions under which the profile was actually checked.

The next step is concrete: choose one agent handoff, add an explicit stale state, and require the receiving workflow to name its next transition. Keep the evidence with the artifact, re-check only what changed, and stop at the boundary where authority is missing. Trust then becomes a bounded, inspectable promise rather than a snapshot the system quietly outgrows.