Research question
How should enterprise teams model delegated authorization when an AI agent invokes tools or MCP servers on behalf of a user, without collapsing user identity, agent identity, and tool-scoped privileges into a single bearer token?
This research investigates authorization boundaries between:
- the human principal initiating work,
- the agent runtime executing plans,
- MCP hosts and tool endpoints acting as separate security domains.
The question is exploratory. It does not define final EAISF Framework controls.
Why it matters
Enterprise agent platforms increasingly chain together:
- user-authenticated sessions,
- agent orchestration runtimes,
- MCP tool servers with their own credentials and data scopes.
When these layers share one ambient credential, a compromised prompt path or tool response can expand blast radius across systems that were never intended to trust the agent equally. Authorization must become explicit at each hop rather than implied by network placement alone.
Background
Traditional API security often assumes a single OAuth client acting for a user. Agent architectures add an intermediary that selects tools dynamically, rewrites arguments, and may persist partial state between invocations.
The Model Context Protocol describes a standardized way for agents to discover and call tools. MCP does not, by itself, specify enterprise authorization semantics across organizational boundaries. That gap is where delegated authorization models are still being engineered in practice.
OAuth 2.0 defines delegation patterns such as authorization code grants and scoped access tokens (RFC 6749). Those patterns remain relevant, but agent runtimes introduce additional actors and policy decision points that RFC 6749 did not anticipate.
Analysis
Identity separation
A workable model likely requires at least three distinguishable identities:
- User principal — the accountable human or service account initiating the task.
- Agent runtime identity — the orchestrator executing plans under platform policy.
- Tool invocation identity — the credential presented to a specific MCP server or API.
Collapsing these identities simplifies early prototypes but removes audit clarity and prevents least-privilege scoping per tool category.
Scope propagation
Delegation is not only authentication. Policy must answer:
- Which tools may the agent discover at all?
- For each allowed tool, which operations and resource patterns are permitted?
- How are scopes narrowed when a user’s intent is ambiguous?
- What happens when a tool attempts to escalate scope mid-session?
These questions mirror classic authorization design, but agent autonomy makes static scope assignment insufficient without runtime policy evaluation.
Boundary enforcement points
Candidate enforcement locations include:
- the agent control plane before plan execution,
- an MCP gateway that validates outbound tool calls,
- tool servers that treat agent-presented credentials as untrusted until verified.
No single location is sufficient. Defense in depth implies consistent policy artifacts even when enforcement is distributed.
Proposed model (exploratory)
This research proposes a layered delegation chain for discussion—not adoption as EAISF guidance:
- User authorization establishes a session-bound intent object (task category, sensitivity class, time box).
- The agent runtime receives a derived agent token bound to that intent object and a tool allow list.
- Each MCP invocation exchanges the agent token for a tool-scoped credential at a policy decision point.
- Tool servers validate tool-scoped credentials independently and log all three identities.
The model emphasizes fail-closed behavior: if any delegation step cannot be validated, the tool call is rejected rather than downgraded to a broader credential.
Architecture implications
If validated in production environments, such a model would influence:
- how MCP gateways are placed relative to agent runtimes,
- whether tool discovery is a policy-gated operation distinct from tool invocation,
- how audit pipelines correlate user, agent, and tool events,
- where human approval checkpoints attach in multi-step plans.
These implications remain architectural hypotheses until tested against real enterprise integration constraints.
Relationship to EAISF
This research aligns with EAISF thinking on authorization, tool security, and enforceable runtime boundaries. It does not establish new canonical EAISF requirements. Framework principles such as least privilege and explicit identity remain the authoritative reference points.
Readers should treat findings here as input to future Framework and Architecture work, not as finalized compliance language.
Limitations
This research is based on architectural reasoning and publicly available protocol documentation. It does not include production measurements, formal verification, or vendor-specific control mappings. MCP and agent platforms are evolving quickly; delegation models may need revision as standards mature.
References
- IETF RFC 6749 — The OAuth 2.0 Authorization Framework: https://www.rfc-editor.org/rfc/rfc6749
- Model Context Protocol documentation: https://modelcontextprotocol.io/
- OWASP Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/