SAMP Engineering Notes #08

Who Is Allowed to Tell an AI Agent What to Do? An AI agent may understand an instruction perfectly. That does not mean the instruction is authorized.

As AI agents become more capable, the distinction between understanding a request and having permission to execute it becomes increasingly important.

An agent may receive instructions from a human operator, an automated workflow, another agent, a management system, or an external application.

Some instructions are harmless.

Others may change configurations, restart services, modify infrastructure, or affect systems that people and organizations depend on.

The technical question is no longer simply whether an agent can perform an action.

It is also:

Who authorized that specific action, against that specific target, under which conditions?

This is one of the fundamental problems addressed by the Simple Agent Management Protocol (SAMP).

1. Authentication Is Not Authorization

Consider an AI Agent operating inside a corporate infrastructure environment.

The Agent is connected to an authenticated management system. Its identity has been verified. Its runtime is reachable, and its management profile has been accepted.

Does that mean the Manager can instruct it to perform any operation?

No.

Authentication establishes an identity or validates a communication relationship.

Trust establishes whether the Agent has been accepted under the applicable management policy.

Authorization determines whether a specific operation is permitted.

These are different questions.

SAMP keeps these responsibilities distinct.

A trusted Agent is not automatically authorized to execute consequential management commands.

Likewise, an authenticated Manager does not possess unlimited operational authority.

Identity is not permission. Trust is not unlimited authority.

2. A Conversation Is Not a Security Boundary

Imagine an operator entering the following instruction into an AI-powered management interface:

Restart every unhealthy agent in the production environment.

A language model may understand what the operator intends.

But several questions remain unanswered.

What constitutes an unhealthy Agent?

Which Agents are included?

Is the operator authorized to restart all of them?

Are any of them supporting critical services?

Does the operation require approval?

Should execution occur simultaneously or in controlled batches?

What happens if the operation cannot be completed safely?

The conversational interface does not answer these questions simply by interpreting the sentence.

SAMP -04 makes an explicit architectural distinction:

Natural-language conversation is a user interface, not an authorization or execution boundary.

Before a consequential management operation can be admitted, conversational intent must be resolved into a deterministic, structured action.

That structured action identifies the exact target, operation, parameters, applicable authorization, approval requirements, and execution constraints.

Natural language can express intent. It cannot grant authority.

This also matters when instructions originate from external content or other AI agents. A convincing instruction is not necessarily an authorized instruction.

3. Authorization Must Be Bound to the Exact Action

Suppose a management system receives authorization to restart Agent A.

Can that authorization also be used to restart Agent B?

Can the same authorization be reused to change Agent A's configuration?

Can a parameter be modified after approval?

The answer should be no unless a separate valid authorization explicitly permits the resulting action.

In SAMP, authorization for consequential CONFIG and EXEC operations is bound to the particular operation and its context.

The authorization model considers information such as:

• The authenticated Manager and originating actor.
• The target Agent and its enrollment context.
• The operation type and exact parameters.
• The request identity and cryptographic action digest.
• Applicable policy and profile revisions.
• Authorization authority and decision references.
• Approval, delegation, constraints, and expiration where applicable.

SAMP -04 defines an authorization_digest using SHA-256 over an RFC 8785 canonicalized representation of the authorization-bound action.

But the digest alone is not permission.

The final enforcement component must validate a trusted authorization decision bound to that exact action.

A valid cryptographic identifier cannot replace a policy decision.

An approval for one action must not silently become approval for another.

4. Where Is Authorization Enforced?

Another important architectural distinction concerns enforcement.

A Manager may evaluate organizational policy before issuing a request.

But Manager-side authorization alone is insufficient.

The final Policy Enforcement Point, or PEP, must independently validate the relevant authorization conditions before admitting a consequential operation.

Depending on deployment architecture, this enforcement function may reside in an Agent endpoint, sidecar, gateway, or another independently enforceable component.

This is particularly relevant for heterogeneous AI environments.

A management system may supervise agents built using different frameworks, programming languages, execution runtimes, and infrastructure platforms.

SAMP does not require every framework to implement an identical internal security architecture.

Instead, it establishes a common management-plane contract and requires the final enforcement boundary to uphold the applicable authorization restrictions.

If the required authorization cannot be established, admission must fail closed.

5. Human Authority Is an Engineering Requirement

Human oversight is often discussed as an ethical principle.

In operational systems, it also needs to become an enforceable engineering requirement.

Consider an Agent authorized to investigate a security incident.

It may collect information, correlate events, and prepare a recommended response.

However, terminating a production workload or changing a critical network configuration may require a different level of authority.

An organization's policy may require explicit human approval before such an action.

The important distinction is between an Agent recommending an operation and an enforcement component admitting it.

A human approval, when required, must be associated with the correct action, authority, and applicable constraints.

A generic conversational acknowledgment such as OK, proceed must not automatically become unrestricted permission.

The management infrastructure needs an unambiguous representation of what was approved.

This does not mean every operation requires a human.

Routine, low-impact operations can be authorized through established policies, while consequential operations may require additional safeguards.

The authority boundary depends on policy and operational impact, not merely on whether a human or an AI initiated the request.

6. SAMP Is Not an Identity Management System

An important design decision is what SAMP deliberately does not attempt to replace.

SAMP is not an IAM platform.

It does not define an organization's complete role hierarchy, RBAC or ABAC policy language, approval administration, or delegation infrastructure.

Those functions belong to the organization's authorization systems.

SAMP provides the management-plane mechanism through which an authorization decision can be referenced, bound to an exact management action, validated, and enforced.

This separation allows a SAMP deployment to integrate with existing identity and policy infrastructure instead of creating a competing organizational authority system.

The objective is interoperability, not the reinvention of enterprise security governance.

7. From Policy to Operational Behavior

Consider a hypothetical Agent Management System supervising multiple AI agents.

One Agent detects a problem and recommends restarting another Agent.

An automated workflow prepares the request.

Before execution, the system must determine whether the request is permitted.

A possible operational sequence is:

1. Identify the originating actor and proposed action.
2. Resolve the exact target and operation parameters.
3. Evaluate applicable policy and approval requirements.
4. Obtain a valid action-specific authorization decision.
5. Submit the structured management request.
6. Validate authorization at the final enforcement boundary.
7. Record the admission decision and resulting execution outcome.

This is an illustrative architecture, not a claim that every step has already been implemented or validated in AgMS Alpha.

It also does not imply that SAMP defines the organization's entire approval workflow.

The point is that interpretation, authorization, admission, and execution are separate responsibilities.

And each responsibility needs a clearly defined boundary.

8. Authority Must Remain Verifiable

As AI agents become more integrated into operational infrastructure, their ability to act will continue to expand.

They will diagnose problems, recommend changes, coordinate workflows, and execute permitted management operations.

That increased capability makes authorization boundaries more important, not less.

A capable Agent without a reliable authority boundary creates operational risk.

A capable Agent operating under explicit, enforceable, and auditable authority becomes a more manageable component of the infrastructure.

SAMP does not attempt to decide who should have organizational authority.

It provides a protocol framework for ensuring that consequential management operations respect the authority established by the deployment.

Because the question that matters is not only:

Can the Agent do this?

It is also:

Who authorized it, what exactly was authorized, and who enforces that decision?

About SAMP: The Simple Agent Management Protocol is an experimental, vendor-neutral management-plane proposal for heterogeneous AI agents. Explore the project at samp-protocol.org and read the SAMP -04 Internet-Draft.