> ## Content Index > Fetch the complete content index at: https://samp-protocol.org/llms.txt > Use this file to discover other available public pages before exploring further. # SAMP Engineering Notes #05 - URL: https://samp-protocol.org/authorization-evidence-and-safe-execution/ - Published: 2026-11-05T09:35:02.000Z - Updated: 2026-11-05T09:50:52.000Z - Description: An authorized AI-agent operation is not necessarily executed, and execution is not necessarily verified. Explore how SAMP combines exact-action authorization, runtime evidence, recorded outcomes, and safe recovery. - Author: Stelio E. Efstathiou - Tags: Engineering Notes, SAMP Articles Authorization, Evidence and Safe Execution Imagine a Security Operations Center investigating suspicious activity associated with an AI agent. The monitoring system detects an anomaly. An investigation agent correlates several events and recommends isolating the affected workload. A human security operator reviews the findings and approves the proposed action. The management system sends a request to execute the isolation. The request is accepted. But before the response reaches the Manager, communication is interrupted. **Was the operation authorized? Was it executed? Was the workload actually isolated? Can we prove what happened?** These questions may appear closely related. They are not equivalent. An operation may be correctly authorized but fail during execution. It may execute successfully while the response is lost. It may be reported as successful without sufficient evidence of the intended external effect. And an authenticated management system may request an operation it has no authority to perform. The **Simple Agent Management Protocol (SAMP)** addresses these distinctions through explicit authorization, operation-specific request binding, controlled execution, recorded outcomes, and runtime-evidence mechanisms. This article examines how SAMP version 0.2 approaches these problems and why safe AI-agent management requires more than authenticated API calls. ### 1\. Authentication Is Not Authorization Consider a familiar infrastructure management scenario. A management system establishes an authenticated connection to a managed endpoint. The endpoint recognizes the system and verifies the integrity of its requests. Does that mean the management system may execute every operation exposed by the endpoint? **No.** Authentication establishes the identity associated with a communication exchange. Authorization establishes whether that identity, acting under a particular authority and context, may perform a particular operation. The distinction is fundamental to security engineering. SAMP applies it explicitly. A Manager may be authenticated. The managed Agent may be trusted. The requested operation may be technically supported. Yet the operation may still be prohibited. For example, an authorized monitoring system might be allowed to retrieve operational status but not terminate an AI-agent runtime. Similarly, a security operator may have authority to investigate incidents without possessing permission to execute infrastructure-wide containment actions. **Authentication answers who is communicating. Authorization answers what that actor is permitted to do.** SAMP does not confuse the two. ### 2\. A Trusted Manager Is Not an All-Powerful Manager Traditional centralized management systems often possess extensive operational privileges. That model can create serious risks when applied without sufficient restrictions to AI-agent environments. A single management platform might control agents responsible for development, infrastructure automation, security investigations, or business workflows. If authentication alone granted execution authority, compromising the Manager could expose every managed capability. SAMP therefore separates the trusted management relationship from operation-specific authorization. A trusted Manager does not automatically acquire CONFIG or EXEC privileges. Even when an operation is advertised by the Agent Profile, the final enforcement component must verify whether the particular request is permitted. ### Two Restrictive Policy Boundaries SAMP recognizes two policy responsibilities. **Manager-side policy** determines whether the management authority should initiate the proposed operation. **Endpoint-local policy** determines whether the managed endpoint may admit and execute that operation. Both are restrictive. Manager approval cannot override an endpoint-local denial. An endpoint's declared ability to execute an operation cannot replace the Manager's authorization requirements. This prevents management functionality from becoming unrestricted authority simply because the components can communicate. ### 3\. Authorization Must Be Bound to the Exact Action One of the most significant additions introduced during SAMP's development was its consequential-operation authorization contract. An authorization decision must apply to a specific management request. Not merely to a user. Not merely to a Manager. And not merely to a general category of operations. Consider an operator approving the restart of a particular AI agent. The approval should not silently authorize restarting another agent. It should not authorize deleting the agent's memory. It should not authorize executing a modified command with different parameters. And it should not remain valid indefinitely. SAMP version 0.2 requires an `authorization_context` for core CONFIG and EXEC requests. The authorization information includes references and bindings such as: - The trusted authorization authority. - The originating human or machine principal. - The authorization decision reference. - The applicable policy identifier and version. - A cryptographic digest of the exact authorization-bound action. - The authorization expiration time. - Approval references when required. - Delegation references when applicable. The protocol also binds admission to the expected Agent Profile revision and applicable policy context. ### Why the Authorization Digest Matters The `authorization_digest` identifies the exact action submitted for authorization. It is calculated from a canonical representation of the relevant request, including the target, operation, parameters, request identifier, and associated context. If the operation changes, the authorization binding changes. For example: **Approved action:** Restart Agent A. **Modified action:** Restart Agent B. Even if the same Manager submits both requests, the original authorization cannot simply be reused. Likewise, changing a parameter of an approved operation requires a new authorization decision applicable to the modified request. This establishes an important security property: **Authorization for one action is not authorization for a similar action.** ### A Digest Is Not a Decision There is another essential distinction. A correctly calculated digest does not prove that an authorization authority approved the operation. The final Policy Enforcement Point must retrieve or validate the trusted authorization decision and compare it with the authenticated request. The decision must apply to the correct Manager, actor, Agent, enrollment, operation, policy context, and constraints. A request containing a plausible decision reference or a mathematically correct digest is still only a request until the trusted authorization decision has been validated. ### 4\. Where Does the Authorization Decision Come From? SAMP deliberately avoids defining an organization's complete authorization infrastructure. It does not prescribe one universal implementation of: - Role-Based Access Control (RBAC). - Attribute-Based Access Control (ABAC). - Identity and Access Management (IAM). - Organizational resource hierarchies. - Approval workflows. - Delegation administration. These remain deployment responsibilities. An organization might already use an established IAM platform, policy decision service, privileged-access system, or approval workflow. SAMP defines the protocol contract that allows a decision made by such a system to be bound to a management request and enforced. The final Policy Enforcement Point, or **PEP**, is responsible for validating that decision before execution. Depending on deployment architecture, enforcement may occur within the SAMP endpoint or an independently enforceable management component. ### Human Approval Human approval can be an important part of the authorization process, particularly for consequential operations. However, SAMP does not require a human to approve every management action. Approval requirements depend on the trusted authorization decision and deployment policy. For example, an organization might allow a low-risk configuration adjustment under approved automation policy while requiring human approval before isolating a critical workload. The protocol must preserve and enforce those distinctions. **Human authority should be represented through enforceable policy and approval evidence, not assumed merely because a human appears somewhere in the workflow.** ### 5\. Natural Language Is Not an Authorization Boundary Consider an operator interacting with an AI-assisted management system. The operator writes: "Investigate the suspicious agents and isolate anything dangerous." A conversational AI may understand the intention. But the instruction is not sufficiently precise to authorize a consequential operation. Which agents? What constitutes dangerous? What does isolation mean? Which enforcement mechanism should be used? What is the acceptable operational impact? Who approves the action? A natural-language instruction can contain ambiguity, omitted constraints, or information influenced by untrusted inputs. SAMP therefore treats conversation as a user interface, not as an authorization or execution boundary. Before constructing a consequential SAMP request, the system must resolve the instruction into a deterministic, structured action. That resolution identifies: - The intended target. - The exact supported operation. - Its typed parameters. - Applicable authorization and approval requirements. - Operational constraints such as dry-run, canary, batching, or blast-radius limits where appropriate. Only after this resolution can the proposed management action be evaluated through the applicable authorization process. ### A Practical Example An operator requests: "Restart the failing investigation agent." A conversational interface identifies the intended Agent, resolves the supported management operation, and presents the proposed action for approval when required. The resulting structured request targets the exact Agent and operation. A policy system evaluates the authorization. The SAMP endpoint validates the corresponding decision and applies local enforcement. Only then may execution begin. **An AI system understanding an instruction is not the same as that instruction being authorized.** This boundary is particularly important when conversational systems can trigger changes affecting external infrastructure. ### 6\. CONFIG and EXEC Are Different Operations SAMP defines two distinct mechanisms for changing managed environments. ### CONFIG: Controlled Configuration CONFIG requests changes to explicitly declared writable fields. The Agent Profile identifies which fields are configurable and the types of values they accept. The endpoint validates the request against those declarations and the applicable policy. An unknown, unsupported, unauthorized, or policy-disabled field must not be modified. For example, a deployment may expose an operational logging threshold as a configurable field. Changing that value is a configuration operation. It is not unrestricted access to the agent's internal state. ### EXEC: Explicitly Declared Execution EXEC requests a declared management operation. A deployment might expose a controlled restart operation, a diagnostic action, or another explicitly supported management function. Such operations must have declared command names and typed parameters. Arbitrary shell commands and unrestricted free-form execution are not part of the core EXEC model. **EXEC is disabled by default.** Enabling it requires explicit local provisioning, declared operations, and applicable authorization and audit controls. ### Why the Separation Matters Changing a configuration value and performing a potentially consequential external operation can have different operational effects. Both require authorization under SAMP 0.2, but the specific policies, constraints, and safeguards may differ. The protocol preserves those distinctions instead of treating all management writes as interchangeable commands. ### 7\. Admission Is Not Execution Now return to our hypothetical SOC incident. The operator approves isolation. The authorization authority issues a valid decision. The final PEP verifies that the request is permitted. The endpoint admits the operation. Has isolation succeeded? **Not necessarily.** Admission establishes that the request passed the relevant controls and was accepted for execution. Execution is a separate process. The operation may still be running. It may fail. It may partially complete where the applicable operation semantics permit partial outcomes. Or its result may remain unknown. SAMP version 0.2 represents authorization and execution outcomes separately. ### Policy Outcomes The protocol defines: - `allow` - `deny` - `indeterminate` These describe the admission or authorization decision. ### Execution Outcomes The protocol separately defines: - `not_executed` - `in_progress` - `succeeded` - `partially_succeeded` - `failed` - `indeterminate` Not every combination of policy and execution outcomes is valid. For example, a policy denial cannot be reported as a successful execution. A confirmed failure after an authorized operation began is not equivalent to an authorization denial. `partially_succeeded` belongs to core CONFIG semantics; core EXEC does not use it without an explicitly identified extension. **Authorization determines whether an operation may proceed. Execution outcomes describe what is known about the attempt.** These concepts must remain independent in both protocol records and operational interfaces. ### 8\. What Happens When Authorization Is Unavailable? Distributed systems cannot assume that every supporting service will remain continuously available. An authorization authority may become unreachable. A required approval status may be unavailable. A delegation record may have expired. A policy decision may be impossible to validate. What should the endpoint do? It must not interpret missing authorization information as permission. SAMP defines fail-closed behavior for such conditions. Relevant outcomes include: - `authorization_expired` - `approval_required` - `step_up_required` - `delegation_invalid` - `policy_unavailable` These outcomes do not all mean the same thing. A denied operation is not necessarily an operation waiting for a temporary dependency. A request requiring additional approval is not the same as a request whose authorization has been revoked. A temporary inability to establish required policy state does not authorize execution. SAMP also defines bounded handling of retries following `policy_unavailable`, including a non-executable request reservation that protects against conflicting reuse of the same request identity. **Fail closed does not mean fabricate a permanent denial. It means do not execute until the required authority can be established.** ### 9\. Execution Safety: The Lost Response Problem Now consider another hypothetical scenario. A Manager sends an authorized request to restart a managed workload. The endpoint validates the request. The restart operation executes. But the response is lost. The Manager receives no confirmation. What should it do? A simplistic implementation might retry the operation immediately. But that could cause a second restart. The original operation may already have succeeded. The Manager simply lacks the result. SAMP therefore requires explicit request identity, authenticated request binding, duplicate protection, and recorded-operation handling for consequential operations. A repeated request matching an existing admitted operation must not initiate the external effect again. Where the relevant record remains available, the endpoint can return its recorded outcome, subject to authentication and disclosure policy. If the outcome is uncertain, that uncertainty must be preserved. ### Why Exactly-Once Execution Is Difficult A distributed system cannot generally guarantee exactly-once external effects merely by assigning request identifiers. The managed endpoint may fail between performing an external action and recording its result. The external system may not support idempotency. The response may be lost after an operation succeeds. The record store may become unavailable during recovery. SAMP does not promise universal exactly-once execution. Instead, it defines safeguards against unsafe repeated admission and requires explicit treatment of uncertain outcomes. **A timeout is not proof of execution failure.** And a new request identifier must not be used simply to bypass uncertainty about an earlier consequential operation. ### 10\. Runtime Evidence: What Can We Actually Prove? Authorization and execution outcomes describe important operational facts. But what happens when those facts must be independently verified? Consider an agent reporting: "Isolation completed successfully." What does that statement prove? It proves, at most, that the reporting component made the claim and, depending on the authentication mechanism, that the message came through an authenticated channel. It does not automatically prove that the external environment was isolated. Perhaps the isolation API returned success without applying the expected restriction. Perhaps the reporting process was compromised. Perhaps the restriction affected the wrong workload. Or perhaps the network restriction was applied successfully, but an independent verification step has not yet completed. SAMP version 0.2 defines a generic runtime-evidence representation to support such scenarios. ### Evidence Has Its Own Context Runtime evidence can identify: - The subject of the evidence. - The evidence issuer. - The sender or relay, where different. - The validator and enforcement actor, where applicable. - The evidence phase. - The policy verdict associated with the evidence. - Its processing and verification status. - The evidence format. - Correlation information. - Freshness information. - Relevant verifier deployment characteristics. Evidence may be associated with pre-admission checks, post-execution outcomes, or operational state observations. It can be transported through existing SAMP mechanisms, including PUSH and supported CONFIG/EXEC outcomes. However, the core protocol does not mandate one universal external evidence format or verification technology. ### 11\. Verified Evidence Is Not Automatically Proof of Success This distinction is particularly important. Suppose a verifier produces a correctly authenticated receipt. The receipt is valid. Its integrity is intact. Its issuer is known. Its freshness and correlation checks pass. Does that mean the operation succeeded? **Not necessarily.** It depends on what the receipt actually establishes. A receipt may prove that: - A particular runtime condition was observed. - A policy evaluation was completed. - A request passed a verification step. - An enforcement component accepted a command. - A specific external effect was independently established. These are different claims. SAMP explicitly separates the verification status of evidence from the execution result of a managed operation. For example, evidence confirming a valid authorization decision does not establish that an authorized restart occurred. Similarly, observing that a workload is offline does not prove that a particular isolation request caused that condition. Another actor or unrelated failure could have produced the same observation. **The evidence must establish the claim being made, including causal attribution when required.** That is the difference between collecting evidence and establishing an operational fact. ### 12\. Evidence Provenance and Failure Domains Evidence is more useful when its origin and limitations are understood. Consider two possible verification arrangements. **Scenario A: Self-Reported Evidence** The same agent process performs the requested operation and reports the outcome. This may provide useful information. But if that process is compromised or fails, its assertions may not satisfy the organization's assurance requirements. **Scenario B: Independent Verification** An authorized external component observes the relevant enforcement mechanism and produces evidence about the resulting state or effect. Depending on its actual independence, authority, and verification contract, this may provide stronger assurance. However, using an external component is not sufficient by itself. A verifier operating on the same compromised host may share important failure modes with the workload. SAMP therefore distinguishes evidence issuer identity, transport sender identity, and relevant verifier deployment characteristics. It also requires evidence freshness and correlation to be evaluated. **Evidence is not independent merely because it was produced by a component with a different name.** Independence must be established against the relevant failure and compromise scenarios. ### 13\. Can Evidence Resolve an Unknown Execution Outcome? Now return to the lost-response scenario. An authorized operation was admitted. The endpoint recorded its execution outcome as: `indeterminate` Later, a trusted verification mechanism produces evidence about the original operation. Can the recorded result be updated? Under the appropriate SAMP 0.2 conditions, yes. But not simply because new information has appeared. The evidence must be validated against the original operation and satisfy the applicable effect-evidence requirements. These include authenticated binding to the original Manager, Agent enrollment, authorization decision, request identity and digest, and captured profile and policy context. The evidence must establish the terminal effect being claimed. A health observation alone is insufficient if it cannot establish that the original operation caused the observed state. ### Resolution Is Not Re-Execution The purpose of evidence-backed resolution is to determine what happened. It is not permission to perform the operation again. The original operation identity remains unchanged. The recorded outcome may advance from indeterminate to a supported terminal outcome only through the authoritative operation-record owner and the required evidence-validation process. The prior uncertainty must remain available in the audit history. **Recovery of knowledge is not authorization to repeat an action.** That principle is essential for safely managing external effects. ### 14\. Recorded Outcomes and Audit Integrity SAMP version 0.2 introduces an important mechanism for tracking authoritative consequential-operation records. The mechanism is called: `record_revision` Each authoritative CONFIG or EXEC operation record begins with a revision and advances when its material recorded outcome changes. For example, consider a hypothetical operation. | Record | Execution state | Explanation | | ---------- | --------------- | --------------------------------------------------------------- | | Revision 1 | indeterminate | The endpoint cannot establish the final effect | | Revision 2 | succeeded | Validated evidence establishes the original operation's success | This example assumes all requirements for evidence-backed resolution are satisfied. The revision change does not create a second execution. It represents a change in the authoritative recorded knowledge about the original operation. Previous revisions remain part of append-only audit history. ### Protection Against Conflicting Records A Manager must not accept an older revision as a replacement for a newer authoritative record. If two records claim the same revision but contain conflicting authoritative outcomes, that conflict must be detected and recorded rather than silently resolved by arrival order. If the endpoint cannot establish which committed revision is authoritative after a failure, it must not invent a current result or initiate another external effect. SAMP provides fail-closed behavior for this condition. ### Audit Persistence Is Another Independent Dimension SAMP also distinguishes execution outcomes from audit persistence. An operation might have succeeded while required audit storage failed. That does not make the external effect disappear. Equally, an execution-success result does not prove that all required evidence was durably recorded. The protocol represents audit-persistence status separately as: - `complete` - `failed` - `unknown` This preserves an important operational truth. **Execution success, evidence verification, and durable audit recording are different properties.** They must not be collapsed into a single success indicator. ### 15\. Interoperability with External Security Mechanisms SAMP intentionally leaves room for complementary authorization and runtime-verification technologies. Its purpose is not to replace every existing security mechanism. It defines the management protocol and the required binding and enforcement boundaries. This creates opportunities for independent interoperability work. ### SAMP and Correctover Conformance Shape (CCS) CCS is relevant to experimental runtime-evidence verification. An optional CCS-to-SAMP binding could define how a CCS receipt is correlated with a SAMP request and how its claims are validated. Such a binding must preserve issuer authenticity, integrity, operation correlation, and the precise meaning of the evidence claim. A runtime verification verdict must not automatically be promoted into proof of a consequential external effect. CCS is not a mandatory dependency of core SAMP. ### SAMP and EMILIA EMILIA is relevant to potential interoperability around verifiable authorization of exact actions. An experimental integration could explore how an independently issued authorization artifact is validated against SAMP's `authorization_context`. The important objective would be preserving the exact action binding, authorization validity, approval or delegation constraints, and endpoint enforcement requirements. This would not eliminate the final SAMP PEP. Nor would it automatically establish that an authorized operation succeeded. These are possible interoperability directions, not declarations of completed integration or independently validated conformance. **Interoperability should preserve security boundaries, not bypass them.** ### 16\. What Does Safe Execution Look Like in Practice? Let us bring the concepts together. Consider a hypothetical SOC operation involving a suspicious AI agent. The organization has implemented an explicitly declared containment operation through a suitable independent enforcement component. The workflow proceeds as follows. ### Detection Monitoring identifies suspicious activity. An investigation agent correlates available operational information and recommends containment. ### Action Resolution The management interface resolves the recommendation into a deterministic action identifying the exact target, operation, parameters, and applicable constraints. ### Authorization The authorization infrastructure evaluates the request. If required, a human operator approves the specific action. A trusted authorization decision is produced. ### Admission The SAMP endpoint validates the authenticated request, expected profile, authorization decision, and local policy. If the required checks fail, the operation is not admitted. ### Execution The authorized enforcement component performs the supported operation. Execution may succeed, fail, remain in progress, or become indeterminate. ### Verification Where required, appropriate runtime evidence is collected and validated. The evidence must establish the relevant claim, not simply repeat the requested intention. ### Recording The operation outcome, authorization bindings, and required audit state are recorded. Material revisions to the authoritative outcome receive new record revisions. ### Reconciliation If the original result is unknown, recovery procedures investigate and reconcile that result without automatically repeating the external effect. This is an illustrative deployment workflow. SAMP defines the management protocol contracts involved, not the organization's complete SOC orchestration process or a universal isolation command. The distinction matters. **The protocol can support accountable management without becoming the orchestration engine itself.** ## 17\. From Protocol Design to Experimental Validation The **Agent Management System (AgMS)** is an Alpha-stage experimental application developed to evaluate SAMP management concepts across heterogeneous AI-agent environments. Its development has included management exchanges, authentication, agent monitoring, event handling, operational workflows, and controlled failure scenarios. These experiments provide useful engineering experience. However, they do not automatically establish complete conformance with the authorization, evidence, and recorded-state requirements introduced or refined in SAMP-04. Further validation is necessary. Particularly valuable tests include: - Valid and invalid authorization decisions. - Modified request parameters after authorization. - Approval and delegation failures. - Expired authorization and unavailable policy authorities. - Duplicate consequential requests. - Lost responses after external effects. - Conflicting operation-record revisions. - Failed audit persistence. - Evidence with incorrect issuer or operation bindings. - Evidence that proves a policy verdict but not an external effect. - Reconciliation of indeterminate outcomes without re-execution. Independent implementations and adversarial testing are especially important because they can expose hidden assumptions in a protocol's security model. ## 18\. The Management Plane Is Not the Authorization Authority One final architectural distinction deserves attention. SAMP does not attempt to become the organization's universal security authority. The management plane communicates with managed endpoints and conveys authorization-bound requests. The authorization infrastructure determines which actions are permitted under the organization's policies. The endpoint or independent enforcement component applies the final admission and execution restrictions. Evidence systems establish the specific claims they are designed to verify. Audit mechanisms preserve the corresponding operational history. These responsibilities may be integrated within a deployment, but they must remain distinguishable. **The management plane coordinates operational control. It does not manufacture authority, execution truth, or evidence.** That separation is fundamental to SAMP's security architecture. ## Conclusion: Permission Is Not Execution. Execution Is Not Proof. AI agents are increasingly capable of affecting systems beyond their own runtime environments. They may change configuration, invoke tools, manage infrastructure, or trigger other consequential actions. That creates an operational responsibility extending beyond ordinary authentication and monitoring. SAMP version 0.2 addresses this responsibility through explicit authorization contracts, exact-action binding, endpoint-local enforcement, recorded outcomes, runtime evidence, and failure-aware recovery. The essential principles are straightforward. **An authenticated Manager is not automatically authorized.** **An authorized operation has not necessarily executed.** **An executed operation is not necessarily independently verified.** **A verified receipt proves only the claims supported by its verification contract.** **An uncertain result must not become permission to repeat an external effect.** And perhaps most importantly: **Operational accountability requires us to distinguish what was requested, what was authorized, what happened, and what can actually be proven.** These are not theoretical distinctions. They are the foundations of reliable and secure infrastructure management. As AI agents become operational entities, those foundations become increasingly important. **The objective is not simply to make AI agents capable of acting.** **It is to ensure that consequential actions remain explicitly authorized, operationally controlled, and supported by evidence appropriate to the claims being made.** That is the engineering purpose of authorization, evidence, and safe execution in SAMP. ## Technical References - [SAMP Internet-Draft, Revision -04](https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/04/?ref=samp-protocol.org) - [SAMP Protocol Overview](https://samp-protocol.org/protocol/) - [SAMP Implementations](https://samp-protocol.org/implementations/) - [Contribute to SAMP](https://samp-protocol.org/contribute/) Technical feedback: [ietf@samp-protocol.org](mailto:ietf@samp-protocol.org) --- *SAMP Engineering Notes is a technical article series exploring the architecture, security, implementation, and interoperability challenges of the Simple Agent Management Protocol.* *Previous: Trust, Liveness and Failure Domains.* *Next: SAMP in Practice: Introducing AgMS Alpha.*