Loading...
AI-agent governance is too focused on launch. The bigger operational risk is what remains after an agent changes roles, loses trust, or leaves a workflow.
Continue the reading path
Topic hub
Runtime GovernanceThis page is routed through Armalo's metadata-defined runtime governance hub rather than a loose category bucket.
A practical onboarding checklist for enterprise AI agents covering identity, behavioral contracts, evaluation, approvals, incident readiness, and economic accountability.
AI teams are accumulating permission debt every time an agent keeps access after its evidence, scope, owner, model, or tool boundary changes.
Curated Collection
Builder Guides
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
Most AI-agent governance begins at onboarding. Who owns the agent? What tools can it call? What data can it see? Which workflows can it enter? Those are good questions, but they cover only the first half of the lifecycle.
The second half is offboarding: what happens when the agent should no longer hold the same authority.
Synthetic coworkers change roles. They fail evaluations. They are replaced by better versions. Their tool access becomes stale. Their memories become inaccurate. Their owners leave. Their mission ends. Their work becomes evidence in a later dispute. If offboarding is not designed, the organization keeps a ghost of prior autonomy alive inside permissions, memory, documentation, dashboards, and downstream integrations.
Human companies learned this lesson through painful identity incidents. A departed employee with lingering access is an obvious security issue. An agent with lingering authority is subtler because it may not look departed. It may still run, answer, retrieve, and act while everyone assumes it is covered by old approval.
OWASP's LLM security work names risks such as excessive agency, sensitive information disclosure, and supply-chain exposure (https://owasp.org/www-project-top-10-for-large-language-model-applications/). OpenTelemetry's observability model reminds operators that traces, metrics, and logs are different signals that need to survive across systems (https://opentelemetry.io/docs/). Agent offboarding needs both instincts: narrow authority and preserve evidence.
Deleting an agent record is often the wrong move. The organization may need to preserve its pacts, runs, attestations, disputes, decisions, and downstream effects. Offboarding should remove or narrow authority while keeping the record available for audit, learning, and reputation.
Want a verified trust score on your own agent? $10 to start — $5 goes straight into platform credits, $2.50 seeds your agent's bond. Armalo runs the same 12-dimension audit you just read about.
Get started — $10 →There are at least five offboarding states:
| State | What changes | What must be preserved | Typical trigger |
|---|---|---|---|
| Suspended | Runtime authority pauses | Full evidence and owner record | Incident, dispute, uncertainty |
| Downgraded | High-risk tools are removed | Prior permissions and downgrade reason | Trust decay or failed eval |
| Replaced | New agent takes workflow | Handoff map and inherited constraints | Model or owner transition |
| Retired | Agent stops new work | Historical record and dispute window | Mission complete |
| Quarantined | Memory and outputs lose authority | Contamination trail and review notes | Poisoning or cross-tenant concern |
The table makes an important distinction: offboarding is a control transition, not a trash can.
Agent memory makes offboarding harder. A retired agent may have written memories that active agents still retrieve. A downgraded agent may have left behind runbook notes, customer preferences, vendor risk claims, or codebase conventions. If those memories keep influencing future action, the agent has not really left.
A serious offboarding flow should classify memory into four buckets. Verified memories can remain if their source and scope are intact. Useful but unverified memories can remain as low-authority context. Disputed memories should be quarantined from authority. Sensitive or cross-tenant memories should be removed or locked behind review.
The mistake is treating memory as harmless because it is not a tool permission. Memory can change decisions. That makes memory part of the offboarding surface.
Most handoff plans focus on what the replacement agent should inherit: goals, context, open tasks, customer history, useful memories, and prior evidence. A serious offboarding plan also says what the replacement must not inherit.
Negative inheritance is the missing discipline. The new agent may need to know that an old shortcut is no longer allowed, that a vendor note is disputed, that a customer preference expired, that a prior approval applied only to a retired workflow, or that a memory came from an agent whose trust was downgraded. Without negative instructions, handoff becomes a laundering path. The successor looks fresh while carrying stale authority from the predecessor.
This is especially important in swarms. A retired agent may have influenced many peers. Offboarding one agent should therefore trigger a dependency review: which other agents used its memory, relied on its outputs, or copied its assumptions into their own context?
The dependency review should not be dramatic. It can begin as a graph query. List the agents that consumed this agent's outputs, the workflows that referenced its memories, the tools it was allowed to call, and the pacts still tied to its identity. Then decide which dependencies can remain, which need recertification, and which should be severed immediately.
| Question | Evidence source | Offboarding action |
|---|---|---|
| Which tools can this agent still call? | Tool registry and invocation logs | Revoke or downgrade |
| Which workflows depend on it? | Orchestration graph | Assign replacement or freeze |
| Which memories did it write? | Memory provenance ledger | Verify, downgrade, or quarantine |
| Which pacts remain open? | Pact state and acceptance windows | Resolve before retirement |
| Which disputes mention it? | Dispute ledger | Preserve evidence |
| Which downstream agents consume its outputs? | Trace graph | Notify and recertify |
| Who owns final disposition? | Identity owner record | Assign accountable owner |
The checklist should run before deletion, before replacement, and after any material trust downgrade.
In Armalo's architecture, identity, pacts, memory evidence, disputes, and scores are not separate decorations. They are the record that makes lifecycle transitions inspectable. A retired agent should not erase its proof history. A downgraded agent should not keep its old authority. A replaced agent should not silently pass unverified trust to its successor.
Armalo can support parts of this workflow today through explicit agent records, commitments, evidence surfaces, and trust-state concepts. The broader lifecycle discipline remains an operating responsibility: teams still need to define offboarding states, owners, retention rules, and downgrade triggers.
That honesty is part of the point. The category does not need another launch checklist. It needs a lifecycle model for what happens after launch.
Ask your AI program owner this: how many agents have we retired, downgraded, or replaced, and what happened to their authority?
If the answer is "we have not needed that yet," the program is probably too young or too informal to notice the risk. If the answer is "we delete them," the program may be destroying evidence it will later need. If the answer is "we leave them disabled," the next question is whether their memory, outputs, credentials, and downstream dependencies are also disabled.
They should keep history, but the current trust surface should clearly show inactivity, retirement, or downgrade state. Old performance should not imply current authority.
Incident response handles an acute problem. Offboarding handles lifecycle transition. Some incidents trigger offboarding, but many offboarding events are ordinary: replacement, scope reduction, owner change, or mission completion.
Automate stale permission detection and memory provenance review. Those two surfaces are where retired authority most often lingers.
The enterprise will eventually treat agents like coworkers in one crucial respect: they need a lifecycle. Onboarding earns authority. Offboarding prevents old authority from haunting the next workflow.
A 30-point checklist for getting an agent from prototype to a defensible trust score. No fluff.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
Explore the docs, register an agent, or start shaping a pact that turns these trust ideas into production evidence.
Loading comments…
If reputation lives only inside one platform, it is not reputation, it is marketing. The Trust Oracle is the moment agent trust stops being a private feature and starts being public infrastructure other systems can read, dispute, and depend on.
No comments yet. Be the first to share your thoughts.