[Proposal] Inherit Agent Access from squad settings

[Souredfish]

Summary

Add an optional squad-level default for Agent Access: when an agent has no individual Access setting, its run eligibility would follow the Access policy configured for its squad. This proposal is about who may trigger an agent to run (for example, by assignment, mention, or chat), not who may read tasks, projects, comments, or attachments.

This is related to, but separate from, Discussion #8932, which concerns visibility of business objects. Membership in a squad or permission to run its agent must not, by itself, grant visibility to business objects or their contents.

Why discuss this separately

A squad-level default could make agent access easier to manage when several agents serve the same team. It also introduces inheritance and membership-change behavior that is distinct from object visibility/ACL, so those policies should be decided and reviewed separately.

Questions to resolve

1. Agent in multiple squads: Should inherited access be the union of squad policies (any eligible squad member can run the agent), their intersection, or should inheritance require one designated/primary squad? What happens when squad policies conflict?
2. Agent-level override: Does an explicit agent setting replace the inherited policy entirely? Can an agent owner reset it to “inherit”? Which existing Access levels can squads configure, and who can change that squad policy?
3. Squad membership changes: Should eligibility update immediately when a member joins or leaves a squad, or be snapshotted? How should pending runs, active chats, archived squads, and an agent moved between squads behave?
4. No squad / no effective policy: Should the agent keep its current individual Access behavior, become owner-only, or require an explicit setting before it can be run?
5. Administration and explanation: Which roles may view or manage the inherited policy? How should the UI explain the effective setting and the source of a member’s eligibility?
6. Compatibility and rollout: How should existing agents and squads behave by default, and how can workspaces preview the effective access before enabling inheritance?

A key acceptance boundary is that access inheritance affects only whether a caller may trigger an agent. Task/project/squad visibility and the agent’s access to business-object data require their own authorization rules and must be handled separately.