Capabilities, Authority, and Execution Boundaries

An agentic system is useful only when it can affect something beyond the model response: retrieve private data, run a computation, change a record, send a message, operate software, or delegate work. Architecture begins with those reachable effects and their boundaries—not with the names a framework gives to its interfaces.

Tools, Agent Skills, Actions, plugins, and protocols are common implementation forms. None is a universal building block of agent architecture. The same capability might be exposed through a typed API, a graphical interface, a command sandbox, a workflow transition, or another agent; a skill might describe how to use any of them without granting access to one.

Thesis

Model capability, system authority, and external effect are different things. The architecture must decide what the system can reach, enforce who may do what under which conditions, and verify what actually changed.

A model may know how to compose an email without being able to read an inbox. An application may expose a send operation while the current run lacks permission to use it. An accepted request may still time out after partially changing the environment. Treating these as one “tool call” hides the distinctions on which reliability and security depend.

Start from effects, not interface names

Before choosing a framework, map how the system can observe or change its environment. A useful classification is:

Capability class	Architectural question	Examples
Observe	Which facts may enter the run, from which source and at what freshness?	Read a record, inspect a page, receive an event
Compute	Which isolated transformation may run, with what resources?	Execute code, parse a document, calculate a route
Communicate	Who may receive which information, under whose identity?	Draft or send a message, publish a response
Stage	Which potential change can be prepared without committing it?	Produce a diff, reserve inventory, prepare a payment
Commit	Which external state may actually be changed?	Update a database, deploy software, transfer funds
Delegate	Which objective, authority, data, and limits may be passed onward?	Start a workflow, ask another agent, assign a human task

These classes are not a universal taxonomy. They are a design aid for discovering consequences that an interface label can conceal. “Use browser” may observe public text, disclose private data in a form, and submit a purchase. “Call assistant” may delegate to a service with broader authority than the caller. Classify the full reachable effect, not the first hop.

Risk is usually determined by the affected resource, scope, reversibility, destination, and uncertainty—not by whether the interface happens to be called a tool. Reading one public page and exporting an entire customer database are both reads, but they do not belong inside the same control boundary.

Separate capability, authority, and effect

For every consequential path, distinguish three questions:

Capability: What operation can this system technically request or perform?
Authority: Which principal may exercise it, on whose behalf, over which resources, under what policy and time limit?
Effect: What operation was proposed, accepted, and attempted, and what result was finally observed in the environment?

This separation prevents several category errors. Model competence does not create system access. Interface discovery does not grant permission. Authentication establishes an identity but does not by itself authorize an operation. A model statement that work succeeded is not evidence that the effect occurred.

Saltzer and Schroeder define a principal as the unit to which authorizations are granted and emphasize complete mediation and least privilege as protection principles (Saltzer and Schroeder, 1975). Those principles remain applicable when a model selects operations: each protected access still needs enforcement at a boundary the model cannot bypass.

Define an authority chain

An agent rarely acts only as itself. It may operate for a user, an organization, a service account, or a parent agent. Record the chain explicitly:

requesting actor
  -> accountable principal
  -> delegated objective and scope
  -> runtime identity and credentials
  -> policy decision
  -> executor
  -> affected resource and destination

Authorization should bind the current request to at least the principal, operation, resource, tenant, data classification, limits, relevant state, and expiry. It may also depend on the destination, amount, rate, environment, or approval evidence. Long-lived ambient credentials make these distinctions difficult to enforce; narrowly scoped and short-lived delegation reduces the impact of a mistaken or manipulated decision.

NIST’s 2026 concept paper on software and AI agent identity treats identification, authentication, authorization, delegation, logging, and data-flow tracking as separate concerns. It specifically raises dynamic authorization, least privilege, proof of authority, conveyed intent, and “on behalf of” delegation as open architectural requirements (NIST NCCoE, 2026). It is a draft concept paper rather than a finished standard, but its separation of concerns is useful.

Do not place credentials or unrestricted secrets in model-visible context. The model may propose an operation; a deterministic enforcement point should resolve credentials, evaluate policy, and invoke the executor. Policy must be checked when access occurs, not inferred from an earlier prompt or from the fact that an integration was installed.

Turn intent into a controlled effect

A model output is an untrusted proposal. For consequential work, use an intent-to-effect path such as:

Interpret: derive a bounded intended operation from the goal and current state.
Validate: check structure, types, policy, authority, budgets, and preconditions.
Stage: produce a preview or pending change when the effect benefits from inspection.
Authorize: obtain a policy decision or approval tied to the concrete effect.
Execute: perform the accepted operation through a controlled component.
Observe: retrieve evidence of the environment’s resulting state.
Reconcile: compare the observed result with the intended effect and update authoritative task state.

Not every operation needs all seven stages. A pure calculation may validate and execute immediately. A payment or deployment may require staging, separation of duties, and post-commit verification. The architecture should collapse stages only after considering consequence and uncertainty, rather than because a library presents one invocation method.

Meaningful approval concerns an effect, not an abstract integration. “Allow email access?” is too broad. “Send this message and these attachments to these recipients before 17:00?” provides a reviewable object. The Human Oversight chapter owns where a person intervenes; this chapter owns the information and enforcement boundary that make the decision meaningful.

Design contracts around consequences

Whatever invocation mechanism is used, its contract should describe more than input syntax:

purpose and exclusions
inputs, outputs, and data classifications
observable, computational, staged, committed, or delegated effects
principal, required authority, and policy decision point
resource, tenant, destination, and quantitative limits
preconditions and accepted state version
latency, cancellation, and timeout semantics
outcome and error classes
retry, idempotency, and duplicate-effect semantics
reversibility, compensation, and verification method
owner, version, provenance, and dependencies

Prefer domain-level choices over fragile command construction when a stable domain contract exists. A refund_order boundary can constrain order ownership, amount, reason, and approval; an unrestricted shell leaves the model and prompt responsible for reconstructing those controls. Broad interfaces remain valuable in open-ended environments, but they should run inside a sandbox and receive only the data, network access, credentials, and lifetime the task needs.

Agent–computer interface design affects behavior, not merely developer convenience. SWE-agent reported substantial improvement from an interface designed for language-model interaction on software-engineering tasks (Yang et al., 2024). The evidence is domain-specific, but it supports evaluating interface shape as part of the system rather than assuming a more powerful model will compensate for a poor boundary.

Preserve outcome semantics

The execution boundary should distinguish at least:

confirmed success with evidence;
rejected input, authority, or policy;
failure before any external effect;
partial effect;
timeout or interruption with unknown effect;
stale precondition or concurrent modification;
malformed, untrusted, or semantically invalid response; and
accepted delegation whose downstream outcome is still pending.

Do not immediately flatten these states into prose or a Boolean. The control loop may need an operation ID, attempt number, accepted state version, affected resource identifiers, committed-effect evidence, retry eligibility, and reconciliation instructions. A timeout after a write generally requires read-back or reconciliation before retry.

The τ-bench work evaluates final database state and policy compliance in addition to conversation behavior, showing why a plausible interaction trace is insufficient evidence of task success (Yao et al., 2024). Production Engineering will cover distributed delivery, idempotency, compensation, and recovery in depth; the architectural boundary must preserve enough information for those mechanisms to work.

Expose only eligible capabilities

The full set of connected integrations is not the set that should be visible or executable in every model call. Derive the eligible set from:

task purpose and current control-loop state;
requesting principal, delegation, and tenant;
policy, data classification, and effect class;
environment and dependency health;
required approval or separation of duties;
model competence and interface compatibility; and
context budget and overlap among alternatives.

Context Assembly owns which descriptions enter a particular model call. This chapter owns the prior eligibility and enforcement decisions. Hiding an interface from the model can reduce accidental selection, but it is not an authorization control: the executor must reject ineligible requests even if they arrive through a compromised prompt, stale context, nested component, or direct API call.

Metadata received from an external registry, plugin, server, or agent is a claim. Verify ownership, version, integrity, local risk classification, and downstream effects before enabling it. Composition must not silently widen authority: a delegated service, script, workflow, or child agent inherits only the explicitly granted subset and remains accountable to the parent run’s limits.

Map implementation terms to the architecture

Common ecosystem terms can now be placed without treating them as universal primitives:

Implementation term	What it may represent	What it does not establish
Tool	A model-selectable callable interface, often described by a name and input schema	Authority, safety, or the full downstream effect
Agent Skill / Skill	A named package of reusable instructions, references, assets, or scripts	An executable capability or permission merely because it is loaded
Action	A framework-specific operation object, command, transition, or UI concept	A universal lifecycle stage or proof that an effect was committed
Protocol	Discovery, transport, invocation, or interoperability rules	Application policy or end-to-end accountability
Plugin or extension	A product-specific packaging and integration unit	A stable security boundary
Computer use, code execution, API, workflow task, remote agent	Alternative ways to realize observation, computation, change, or delegation	A common risk level or authority model

For example, MCP specifies discoverable tools with schemas and recommends human control for sensitive operations (MCP Tools, 2025). The Agent Skills specification defines a SKILL.md-based package with optional scripts, references, and assets (Agent Skills Specification). These are useful concrete formats. They should be evaluated against the capability, authority, and effect model above; they should not define that model.

Use the named English term when discussing a particular specification or API. In general architecture prose, use the concept actually meant: capability, interface, task knowledge, proposed operation, committed effect, or delegation.

Failure modes

Interface inventory presented as architecture

A diagram lists tools, plugins, and skills but does not identify principals, resources, policies, or external effects. Begin with reachable consequences and trust boundaries, then map integrations onto them.

Model competence treated as authority

Because the model can produce SQL, shell commands, or browser interactions, it receives broad production access. Keep knowledge and access separate; constrain the executor independently of what the model can generate.

Discovery treated as permission

An installed integration or returned registry entry becomes immediately callable. Filter for relevance, but enforce authorization at invocation and again at protected downstream boundaries.

Authentication treated as authorization

A valid agent or user identity is allowed to perform any operation the connected service exposes. Evaluate the requested operation, resource, scope, current state, and delegated purpose.

Description-only control

Natural-language instructions say “never send sensitive data,” but no code checks classification or destination. Convert the requirement into policy, data-flow, schema, and execution controls.

Hidden effect chains

A nominally read-only interface triggers writes, messages, billing, or another autonomous service downstream. Classify and record the complete effect chain.

Boolean or self-reported success

Partial and unknown outcomes appear as success or failure based on model narration. Preserve typed outcomes and verify the environment before advancing the run.

Authority growth through composition

A script, workflow, skill, or child agent brings its own broad credentials. Propagate a narrowed delegation, account for nested cost and effects, and reject authority that the parent could not grant.

Fieldbook guidance

Maintain a capability-and-authority register before choosing implementation packaging:

Field	Question
Purpose	Which task outcome requires this capability, and when is it inapplicable?
Effect	What can be observed, computed, disclosed, staged, changed, or delegated?
Principal	Who is accountable, and on whose behalf does the operation run?
Authority	Which resources, operations, destinations, limits, and duration are allowed?
Enforcement	Which non-model component checks the request, and can every path be mediated?
Contract	What are the inputs, preconditions, outcomes, versions, and failure semantics?
Verification	What evidence confirms the actual external result?
Recovery	Can the operation be retried, reversed, compensated, cancelled, or reconciled?
Composition	Which downstream components receive data or delegated authority?
Ownership	Who reviews changes to the interface, policy, dependencies, and implementation?

Only after this register is clear should the team decide whether a capability is best realized as a Tool, application command, browser interaction, workflow step, script, service API, or delegation to another agent.

Checklist

References and how they are used

Saltzer and Schroeder, “The Protection of Information in Computer Systems” — foundational definitions of principals, permissions, and protected objects, plus complete mediation, separation of privilege, and least privilege. The paper uses capability in the narrower security sense of an unforgeable authorization ticket; this chapter does not use that definition for the broader term system capability. The paper does not discuss modern AI agents.
NIST NCCoE, “Accelerating the Adoption of Software and AI Agent Identity and Authorization” — a 2026 draft concept paper used for its explicit separation of identification, authentication, authorization, delegation, auditing, and data-flow concerns. It identifies open questions and proposed work, not settled requirements or a completed standard.
NIST SP 800-207, “Zero Trust Architecture” — NIST zero-trust publication supporting per-resource access decisions, dynamic policy, and avoiding implicit trust based only on network location or ownership. The chapter adapts these principles rather than claiming SP 800-207 is agent-specific.
Yang et al., “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering” — primary evidence that deliberate agent–environment interface design can affect task performance; results are specific to software-engineering benchmarks.
Yao et al., “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains” — primary research supporting evaluation of environmental state and policy compliance rather than accepting plausible dialogue or self-reported success.
Model Context Protocol, “Tools” — current protocol specification used only as a concrete mapping for model-selectable callable interfaces and human-control considerations.
Agent Skills Specification — current open specification used only to define the named SKILL.md packaging format and progressive disclosure, not a universal agent architecture layer.
OWASP LLM06:2025, “Excessive Agency” — OWASP community risk entry supporting minimized extensions, permissions, and autonomy, plus validation and approval for consequential operations.