[Feature] Per-agent credential scoping and access control

[JackChen-me]

Summary

Add security-scoped credential management so each agent can have restricted permissions, rather than all agents sharing the same access level.

Current State

• AgentConfig supports per-agent apiKey and baseURL — different agents can use different LLM providers
• But this is provider-level isolation, not security scoping — there's no restriction on which tools an agent can call, what system resources it can access, or what SharedMemory keys it can read/write
• A compromised or misbehaving agent has the same access as the coordinator

Community Feedback

u/Mooshux (r/LocalLLaMA):
"The orchestration pattern is interesting, but the credential handling is the part worth thinking hard about. If the coordinator passes its credentials down to subagents, a compromise of any subagent gives an attacker the same access as the coordinator. The safer pattern: each subagent gets a scoped token..."

Proposed Approach

• Tool allowlist per agent (already partially exists via tools config — but not enforced as a security boundary)
• SharedMemory read/write scoping (e.g., agent can only read specific namespaces)
• Optional sandboxing for the bash tool (restricted paths, no network, etc.)
• Credential injection pattern: coordinator passes minimal scoped credentials to subagents

Priority

P2 — Not urgent for local dev/CI use cases. Becomes critical for multi-tenant, untrusted-tool, or production deployment scenarios.

[JackChen-me]

Source: Reddit community feedback

• u/Mooshux

[piiiico]

Good framing on the two-layer gap. The credential injection pattern you're proposing solves access scoping — which agent can call which tools. I want to surface a related but orthogonal gap: identity attribution — which specific agent instance made a given call, verifiably.

The current AgentConfig supports per-agent apiKey for provider isolation, but that key is static config, not verifiable identity. When the coordinator injects scoped credentials into subagents, there's no mechanism to verify after the fact:

• That the subagent you authorized is the one that called the tool (vs a different instance sharing the same key in a parallel run)
• When an agent restarts mid-task (container crash, OOM), it re-appears as a new anonymous actor — the SharedMemory audit trail loses continuity
• For the delegation pattern in [P1] Agent Handoff — delegate_to_agent built-in tool #58 (delegate_to_agent): when agent A delegates to B, B inherits access — but the SharedMemory writes are attributed to a string name, not a cryptographically verified identity

This also matters for the onToolCall middleware proposed in #96. The ToolCallContext carries agentName: string — but a string can be forged or collide across instances. A verified agentId in context would let the callback make policy decisions based on who is actually calling, not just what they claim their name is.

One pattern that addresses this:

Before dispatching to a subagent, the coordinator requests an agent authentication token (AAT) for it — a short-lived JWT signed by a stable Ed25519 key, carrying agent_id, agent_name, and granted scope. The subagent attaches this to calls; downstream systems (SharedMemory, trace events, external APIs) can verify it offline against a JWKS endpoint. agent_id is stable across restarts (derived from a persistent vault seed), so the audit trail stays continuous even when containers restart.

Rough extension to the existing flow:

// coordinator assigns identity before dispatching
const subagentToken = await identityProvider.issueToken({
  agentName: 'researcher',
  teamId: team.id,
  scope: ['file_read', 'grep'],  // mirrors tool allowlist
})

// ToolCallContext gets a verified field (not just string name)
interface ToolCallContext {
  readonly toolName: string
  readonly input: Record<string, unknown>
  readonly agentName: string
  readonly agentId?: string       // stable UUID, JWKS-verified
  readonly agentToken?: string    // raw JWT for downstream forwarding
  readonly runId?: string
  readonly taskId?: string
}

The access scoping (#19) and identity attribution work at different layers and compose cleanly: allowlists answer 'can this agent call this tool at all?', the token answers 'is this actually the agent I authorized?', and the onToolCall middleware (#96) can use both signals.

Disclosure: I'm building AgentLair which implements this identity pattern (Ed25519 AATs, HKDF-derived per-agent keypairs, JWKS-verifiable). Mentioning it because it directly addresses the subagent attribution gap — not as a pitch. The pattern is framework-agnostic and could be implemented independently.

Agreed on P2 for local/CI use cases. The moment this runs in multi-tenant or cross-org deployments, attribution becomes the missing piece that access scoping alone doesn't close. Happy to sketch what the AgentConfig type extension would look like if useful.

[JackChen-me]

Thanks for the analysis. Identity attribution is out of scope for now. Will revisit if multi-tenant use cases emerge.

[JackChen-me]

Reopening — only partially addressed:

Done:

• ✅ Tool allowlist/denylist per agent ([P1] Tool Denylist and Role-Based Presets -- three-layer tool scoping #74 — disallowedTools)
• ✅ SharedMemory context isolation ([P1] SharedMemory Context Isolation -- scope reads by task dependency graph #73 — scope reads by dependency graph)

Still open:

• ⬜ Bash tool sandboxing (restricted paths, no network, etc.)
• ⬜ Credential injection pattern (coordinator passes scoped credentials to subagents)