Design user-sponsored agent sessions for Apollo

[nobodyiam]

Background

Refs #5573 and #5624.

The first incremental step for agent-facing Apollo workflows is an official OpenAPI-based CLI. The more complex authorization model should be designed separately after the CLI surface and security expectations are clearer.

This issue tracks the later design direction for user-sponsored agent sessions.

Problem

Existing OpenAPI automation is based on Consumer tokens. That works for scripts and platforms, but it is not a complete agent authorization model:

• Consumer tokens may be too broad for AI-assisted workflows.
• An agent can be affected by prompt injection or untrusted context.
• Apollo configuration values may contain sensitive data.
• Some operations should be proposed or approved rather than executed directly.
• Audit should distinguish the sponsoring user, the agent/session context, and the actual operation.

Direction

Explore a user-sponsored agent session model:

• A user explicitly creates or approves a bounded agent session.
• The session is scoped to selected apps, envs, clusters, namespaces, and action classes.
• Effective permission is the intersection of the sponsoring user's permission and the session scope.
• High-risk operations require approval or are disabled by policy.
• Sensitive reads are redacted, separately approved, or disabled depending on policy.
• Audit records include user, session, agent/tool metadata, operation, target, and approval state.

Possible scope dimensions

• App scope: one or more app IDs.
• Environment scope: selected envs only.
• Namespace scope: selected namespaces or namespace patterns.
• Action scope: read, diff/propose, config write, release, rollback, permission/admin.
• Time scope: short-lived session expiration.
• Approval scope: operations that require explicit user confirmation.

Open questions

• Should the first server-side model introduce an Agent principal, or only an AgentSession sponsored by a user?
• How should Apollo classify sensitive config values for agent access?
• Which operations can be executed directly, proposed only, approval-required, or disabled by default?
• How should the CLI switch between Consumer token mode and future agent session mode?
• Should MCP or other agent protocol adapters call Portal directly, or go through the same governed CLI/OpenAPI semantics?

Out of scope for the first CLI release

• Implementing the server-side session model.
• Replacing existing Consumer token OpenAPI flows.
• Providing MCP before the trust and audit model is clear.

Acceptance criteria for this design issue

• A concrete trust-boundary proposal is documented.
• Scope and permission intersection rules are defined.
• Sensitive-read and mutation approval defaults are defined.
• Audit metadata requirements are defined.
• Follow-up implementation issues can be split for apollo-openapi, apollo-portal, CLI integration, and protocol adapters.

[github-actions]

🤖 Issue Triage

Thanks for opening this design discussion. The issue is well-structured with clear acceptance criteria and references to related work (#5573, #5624).

This tracks the user-sponsored agent session authorization model as a follow-up to the initial CLI implementation. The scope dimensions, open questions, and out-of-scope items provide a solid foundation for design exploration.

Maintainers can proceed with design discussions and split implementation issues once the trust-boundary proposal is documented.

AI generated by Apollo Issue Triage