SAMP Engineering Notes #04

Trust, Liveness and Failure Domains

Imagine a Security Operations Center monitoring a fleet of AI agents.

An agent appears online. Its management interface responds. Heartbeat messages arrive regularly, and the monitoring dashboard displays a green status indicator.

Everything appears normal.

But the agent's enrollment has been revoked.

Or perhaps the agent is trusted, but its underlying workload has stopped processing tasks.

Or an operator has ordered the agent to be quarantined, yet the component responsible for enforcing isolation has failed.

Is the agent healthy? Is it trusted? Is it safe? Has it actually been isolated?

These are four different questions.

And treating them as one question can produce dangerous operational conclusions.

The Simple Agent Management Protocol (SAMP) addresses this problem by separating trust decisions, endpoint reachability, and enforcement outcomes.

This article examines why those distinctions matter, how SAMP version 0.2 represents them, and why deployment failure domains are essential to reliable AI-agent management.

1. The Problem with a Single Green Status Indicator

Traditional monitoring platforms frequently summarize system conditions through simplified operational states.

Green means operational.

Yellow means degraded.

Red means unavailable.

These visual conventions are useful for quickly identifying potential problems.

However, a single status indicator cannot adequately represent every operational and security property of a managed AI agent.

Consider an agent that continues responding to management requests even though its permission to participate in the environment has been revoked.

From a network perspective, the endpoint may be reachable.

From a management-security perspective, the agent is no longer trusted.

Now consider the opposite situation.

An authorized agent temporarily loses network connectivity.

Its management endpoint is unreachable, but the organization has not revoked its enrollment.

The agent is offline, yet its trust relationship may remain valid.

Reachability is an observation. Trust is a management decision.

Combining them into one status conceals information that operators need to make correct decisions.

SAMP therefore treats trust and liveness as independent properties of each managed agent.

2. Trust: Is This Agent Accepted by Management Policy?

In SAMP, trust describes the Manager's enrollment and security disposition toward a managed agent.

Trust is not established merely because an endpoint responds or advertises a recognizable identity.

The Manager maintains an explicit trust state according to its enrollment requirements and policy decisions.

SAMP version 0.2 defines six states.

These states describe the management relationship, not the agent's current workload performance.

Discovery Is Not Trust

An unknown agent may send a DISCOVER request announcing its identity and capabilities.

The Manager may record that announcement.

But discovery does not automatically establish an authenticated or trusted relationship.

An unauthenticated bootstrap request cannot elevate the agent beyond the discovered or pending conditions.

Enrollment requires the applicable authentication binding, validation, and policy approval.

Trust Is Not Unlimited Authority

Even after an agent reaches the trusted state, its management permissions remain constrained.

A trusted relationship does not automatically enable CONFIG or EXEC.

Consequential operations still require valid authorization and endpoint-local policy enforcement.

Trusted means accepted into the management relationship. It does not mean unrestricted access or execution authority.

Revocation Is Not a Temporary Connectivity Problem

Revocation is a deliberate security decision.

If an agent's trust is revoked, the state is terminal for that enrollment.

A subsequent successful heartbeat cannot restore the revoked relationship.

Returning to normal operation requires a separately authorized enrollment process with the necessary fresh authentication context.

This prevents ordinary connectivity recovery from silently undoing security decisions.

3. Liveness: Can We Reach the Management Endpoint?

Liveness answers a different question.

Has a valid recent observation established that the SAMP management endpoint is reachable?

SAMP version 0.2 defines four liveness states.

These states are derived from authenticated protocol observations and documented deployment thresholds.

The Role of PING

SAMP uses an agent-initiated PING operation.

The Agent sends a heartbeat request to the Manager.

A valid exchange contributes to the Manager's assessment of the Agent endpoint's liveness.

However, an important limitation remains.

A successful heartbeat does not prove that the managed AI workload is functioning correctly.

It does not establish:

• Successful task execution.
• Correct reasoning or planning.
• Continued progress on assigned work.
• Availability of external tools.
• Correct behavior of the underlying model.
• Compliance with security policy.

A management endpoint might remain responsive while the actual AI workload is stalled.

The protocol therefore distinguishes SAMP endpoint reachability from workload-specific operational health.

What Happens When Heartbeats Stop?

The Manager uses configured heartbeat and timeout policies.

An agent may move from reachable to stale when expected valid observations are overdue.

A subsequent transport failure or configured timeout may cause its liveness to become offline.

These transitions must not automatically change its trust state.

An authenticated fresh exchange may later restore the reachable classification.

But a duplicate retry of an old request, stale traffic, or an unauthenticated message must not be used to manufacture fresh liveness.

A heartbeat is evidence of a communication event, not proof of an agent's overall correctness.

4. Trust and Liveness Must Remain Independent

The practical consequence is that the Manager must maintain both dimensions separately.

Consider the following illustrative combinations.

None of these combinations independently proves that the underlying workload is safe or correctly performing its tasks.

This is not a cosmetic distinction for monitoring dashboards.

It affects admission decisions, incident response, audit trails, and automated management workflows.

Who Owns These States?

In SAMP, the Manager owns the authoritative trust and liveness values in its registry.

They are not authoritative assertions supplied by the managed Agent Profile.

An agent must not be able to promote itself to trusted simply by announcing a different value.

Similarly, an agent's assertion that it is healthy cannot override the Manager's independently maintained reachability observations.

This separation establishes a necessary boundary between the managed entity and the authority responsible for managing it.

5. Quarantine: A Decision Is Not an Enforced Isolation

Now consider a more serious scenario.

A SOC identifies suspicious activity associated with an AI agent.

The operator decides that the agent must be quarantined.

The Manager changes its trust state to:

quarantined

Does that mean the agent has been isolated?

No.

It means that the Manager has made a restriction decision.

Actual isolation is a separate operational fact.

The difference becomes critical when enforcement depends on external infrastructure or on components that may themselves be unavailable.

The Four Enforcement States

SAMP version 0.2 defines a separate enforcement_status for quarantine.

A Manager must not display requested or indeterminate enforcement as confirmed isolation.

The enforcement status does not independently grant or restore trust.

A Practical Example

Suppose an agent has been compromised.

The SOC requests quarantine.

The Manager records the agent's trust state as quarantined and initiates the deployment's configured isolation mechanism.

But the enforcement component cannot be reached.

The management decision exists.

The restriction policy exists.

Yet physical or logical isolation has not been confirmed.

An operational dashboard that simply displays "Agent Isolated" would be misleading.

A more accurate presentation would distinguish:

Trust: Quarantined

Enforcement: Requested or Indeterminate

That distinction informs the SOC that additional investigation or intervention may be required.

The difference between requested and applied containment can determine whether an incident remains active.

6. Failure Domains: What Happens When the Agent Itself Fails?

This brings us to another fundamental engineering question.

Where does the management endpoint run, and which failures can it survive?

SAMP does not prescribe a single deployment topology.

A SAMP-compatible management endpoint can be implemented through several models.

Embedded Endpoint

The management interface runs inside the managed AI-agent process.

This may be convenient and efficient.

However, if the agent process crashes, becomes unresponsive, or is compromised, the management interface may fail with it.

An embedded endpoint may provide useful cooperative management but cannot automatically guarantee independent enforcement.

Sidecar Endpoint

The management interface operates in a separate component alongside the managed agent.

This may improve separation of responsibilities.

But placing two containers on the same host does not automatically create independent failure domains.

If the host fails, both components may disappear.

If the sidecar depends on the same runtime or credentials as the managed process, some failures may affect both.

Supervisor Endpoint

A supervisor may manage the lifecycle of the underlying agent process.

Depending on its implementation and authority, it may survive a managed-process crash and support operations such as restart or termination.

However, those capabilities must be established through actual control mechanisms, not assumed.

AI Agent Gateway

A gateway may provide a management boundary between operational authorities and one or more AI agents.

It can support separation of management and workload responsibilities.

SAMP recommends gateway deployment for security-sensitive or higher-autonomy environments.

But a gateway is not automatically trustworthy or independently enforceable simply because it is called a gateway.

Infrastructure-Control Component

A separate infrastructure component may provide management functions outside the managed agent's execution environment.

Depending on deployment design, it may support stronger lifecycle or containment guarantees.

Again, the actual result depends on its control authority, dependencies, and relevant failure domains.

Deployment topology describes where components are placed. Failure-domain analysis establishes what their placement actually guarantees.

7. A Sidecar Is Not a Security Boundary by Definition

This is one of the most important lessons for infrastructure engineers.

The term sidecar describes a deployment pattern.

It does not prove independence.

Consider two configurations.

Configuration A

An AI-agent container and a management sidecar share the same host, container runtime, network dependency, and underlying storage.

If the host becomes unavailable, both components fail.

Configuration B

An AI-agent workload runs on one host, while an independently authorized infrastructure controller operates through separate management and enforcement paths.

A failure of the workload process may leave the controller operational.

Configuration B may offer stronger recovery or containment capabilities for the relevant failure.

But even then, the engineer must verify what happens if the network, hypervisor, storage, credentials, or enforcement service becomes unavailable.

The security boundary is defined by the failures and compromises the architecture can withstand.

Not by its diagram.

How SAMP Represents These Properties

SAMP version 0.2 permits deployment metadata describing properties such as:

• Endpoint deployment model.
• Shared process or host.
• Shared failure domain.
• Established independence.
• Survival of the management path after workload failure.
• Survival of the evidence path.
• Operations that can be independently enforced.

These declarations help the Manager understand the proposed deployment relationship.

However, they are not proof by themselves.

Where stronger guarantees are necessary, the Manager should validate relevant claims against trusted deployment inventory, attestation, or other trusted configuration.

Self-declared independence is not independently verified independence.

8. Can a Failed Agent Enforce Its Own Quarantine?

Consider the following sequence.

An AI agent begins behaving unexpectedly.

The SOC detects the condition and decides to isolate it.

The management endpoint is embedded inside the same process.

The process becomes unresponsive before it can complete the requested action.

What happens?

The Manager may record the quarantine decision.

However, the component responsible for applying the restriction is no longer operational.

The isolation outcome may remain failed or indeterminate.

The organization must not assume that the action succeeded.

An independently enforceable infrastructure component might still be able to restrict network access, terminate a workload, or apply another supported containment mechanism.

But that capability depends on the actual deployment.

SAMP does not define a universal quarantine command or guarantee that every endpoint can forcibly isolate its workload.

It provides the management semantics required to distinguish the security decision from its enforcement result.

If an agent must cooperate in its own isolation, that isolation mechanism may fail precisely when it is most needed.

This is why failure-domain analysis is not an optional afterthought in security-sensitive deployments.

9. Quarantine Does Not Automatically Cancel an Executing Operation

There is an additional complication.

Suppose an agent was trusted when the Manager authorized a consequential EXEC operation.

The endpoint admitted the request.

Execution began.

Shortly afterward, the Manager quarantined the agent.

Does the trust-state transition retroactively cancel the operation?

No.

SAMP distinguishes admission from execution.

An operation already admitted under an earlier valid authorization context may still be running when the trust decision changes.

The new quarantine restricts subsequent admission decisions.

It does not automatically prove that a previously admitted operation failed, stopped, or was reversed.

SAMP version 0.2 does not define a general cancellation PDU.

Forced termination requires a separately supported, independently enforceable mechanism.

This distinction is especially important for operations involving external infrastructure.

Revoking future permission is not the same as undoing an action already in progress.

An incident-response workflow must account for both conditions.

10. Recovery Must Not Restore Trust Automatically

Now consider an agent that has been offline.

Its management endpoint becomes reachable again.

The Manager receives a fresh authenticated exchange.

Liveness may transition from offline to reachable.

But what happens to trust?

It remains governed by the existing trust state and management policy.

If the agent was trusted before the communication failure, it may remain trusted.

However, the Manager may require additional validation before allowing new management operations.

If the agent was quarantined, restored connectivity does not release it from quarantine.

If the agent was revoked, restored connectivity cannot reverse revocation within the existing enrollment.

This separation prevents recovery automation from accidentally bypassing earlier security decisions.

It also avoids an equally undesirable outcome: automatically revoking otherwise valid enrollment merely because of a temporary network outage.

Recovery of connectivity is not recovery of authority.

11. What Should an Operational Dashboard Display?

A useful AI-agent management interface should not conceal these distinctions behind a single status field.

For example, consider the following hypothetical SOC view.

The table reveals significantly more than a collection of green and red indicators.

The operator can immediately identify that:

• Security Analyzer 01 has an accepted management relationship and a reachable endpoint, although workload correctness still requires separate observations.
• Coding Agent 02 has a connectivity problem, not necessarily a trust problem.
• Automation Agent 03 remains reachable, but quarantine enforcement has not been confirmed.
• Investigation Agent 04 requires careful handling because both endpoint reachability and containment outcome are uncertain.
• Unknown Agent 05 must not be treated as trusted simply because it responds.

This is an illustrative operational presentation, not a mandatory SAMP dashboard format.

But it shows how separate protocol states improve operational decisions.

The presentation layer may combine these values into alerts or severity indicators.

It must not erase the underlying distinctions.

12. From Protocol Semantics to Practical Engineering

The Agent Management System (AgMS) is an Alpha-stage experimental implementation exploring SAMP-based management of heterogeneous AI agents.

Its development has included operational monitoring, management integrations, event handling, and controlled failure scenarios.

Those experiments help evaluate how management systems behave when agents or communication paths become unavailable.

However, a successful failure-recovery demonstration is not automatically proof of every trust-transition, quarantine-enforcement, or independent failure-domain requirement introduced in SAMP version 0.2.

Such guarantees require implementation-specific testing.

Important experimental questions include:

• Does the management path remain available when the workload process crashes?
• Can a claimed independent supervisor actually terminate a non-cooperative workload?
• Can the Manager distinguish quarantine decisions from successful enforcement?
• Are trust decisions preserved across ordinary liveness transitions?
• Does restored connectivity bypass any required security revalidation?
• Are contradictory or missing enforcement observations recorded correctly?
• Can operators identify when the system does not know the actual outcome?

These are testable questions.

Their answers must come from implementation evidence rather than architectural labels.

13. Why These Distinctions Matter Beyond Security Operations

Although quarantine and enforcement naturally suggest SOC environments, the same principles apply much more broadly.

Network Operations

An automated network-management agent may remain reachable while its underlying automation subsystem is stalled.

The management plane must distinguish endpoint availability from task completion.

Software Development

A coding agent may lose connectivity during a consequential operation.

The management system must avoid interpreting silence as proof that the operation never happened.

Enterprise Automation

An agent may retain valid enrollment while its runtime becomes temporarily unavailable.

Connectivity recovery should not unnecessarily destroy its trusted identity.

Critical Infrastructure

An agent may require forced containment through an independent control component.

That capability must be verified against the relevant failure domains before being relied upon.

Across these environments, the common principle remains:

An operational decision should be based on what the system can establish, not what its interface merely suggests.

14. The Engineering Principle: Never Confuse Intent, Observation, and Evidence

Trust, liveness, and enforcement represent different kinds of operational knowledge.

Trust expresses a management authority's decision.

Liveness reflects observed endpoint communication.

Enforcement reflects what can be established about a requested control action.

They are related, but not interchangeable.

A Manager might know that an agent must be quarantined.

It might observe that the endpoint remains reachable.

And it might still lack sufficient evidence to determine whether isolation succeeded.

All three statements can be true simultaneously.

The purpose of the protocol is not to eliminate uncertainty by declaration.

It is to preserve that uncertainty explicitly until sufficient evidence supports a stronger conclusion.

This principle is familiar to engineers working with distributed systems, security operations, and critical infrastructure.

SAMP applies it to the management of heterogeneous AI agents.

Conclusion: Reachable Is Not Trusted. Quarantined Is Not Isolated.

AI agents are becoming part of operational infrastructure.

As their capabilities increase, management systems must avoid making security and operational decisions from incomplete or ambiguous observations.

SAMP version 0.2 addresses this problem through independent trust and liveness states, explicit quarantine enforcement outcomes, and deployment-aware failure-domain semantics.

The underlying lessons are straightforward.

An agent can be reachable but untrusted.

An agent can be trusted but offline.

An agent can be quarantined without being successfully isolated.

And an independently enforceable management capability must be demonstrated, not assumed from a topology label.

These are not merely protocol-design details.

They are essential distinctions for reliable monitoring, safe incident response, and accountable operational management.

The goal is not to make every uncertainty disappear.

It is to ensure that operators can recognize uncertainty, act according to policy, and distinguish management intentions from verified operational results.

Because in operational infrastructure, the difference between "isolation requested" and "isolation confirmed" is not a matter of terminology.

It is a matter of security.

Technical References

• SAMP Internet-Draft, Revision -04
• SAMP Protocol Overview
• SAMP Implementations
• Contribute to SAMP

Technical feedback: [email protected]

SAMP Engineering Notes is a technical article series exploring the architecture, security, implementation, and interoperability challenges of the Simple Agent Management Protocol.

Previous: Inside the SAMP Management Plane.

Next: Authorization, Evidence and Safe Execution.