Securing MCP and agentic systems — Common customer questions

Q6 When agents invoke other agents, how do we propagate identity and stop privilege escalation?

When an agent calls another agent, identity and context have to narrow as they move down the chain — never widen. The RFC 8693 token exchange pattern with a nested act claim is the answer at every hop.

The AGW STS ENT mints a fresh, downscoped, audience-pinned token at each hop. The previous caller becomes a nested act claim, so the full chain is recoverable from the token itself:

{
  "iss":   "https://agw-sts.example.com",
  "sub":   "user-12345",
  "aud":   "mcp-finance-advices",
  "scope": "bank-agents",
  "act": {
    "sub": "agent-coach",
    "act": { "sub": "agent-butler" }
  }
}

At sensitive resources, assert the full chain — not just the last actor:

jwt.iss == "https://agw-sts.example.com" &&
jwt.act.sub == "agent-coach" &&
jwt.act.act.sub == "agent-butler"

A single-actor check would miss "skip Butler, user goes straight to Coach". The chain check catches it.

Q10 When should the gateway pause for a human, and how is that approval bound to the request?

Human-in-the-loop is the right answer for irreversible, high-impact actions — Tier 3 in Q4. The shipped answer today lives at the agent runtime, not at the gateway: kagent 0.8.0 added a requireApproval field that pauses tool execution and surfaces an Approve / Reject prompt in the kagent dashboard before the call goes out.

The shipped flow — kagent requireApproval OSS:

1. On the agent's MCP tool-server stanza, list the high-impact tools under requireApproval (must be a subset of toolNames).
2. When the model decides to call one of them, execution pauses before the tool fires.
3. The kagent dashboard renders the pending call — tool name, arguments — and shows Approve / Reject.
4. Approve → the tool executes. Reject → the rejection reason is fed back to the model so it can adapt or pick a different path.
5. Same pattern works through an orchestrator that delegates to a subagent: the approval bubbles up through the chain to the dashboard.

apiVersion: kagent.dev/v1alpha2
kind: Agent
metadata:
  name: k8s-agent
  namespace: infra
spec:
  type: Declarative
  declarative:
    systemMessage: |
      You manage Kubernetes resources. Before deleting or applying,
      the user will be asked to confirm. Explain what you plan to do.
    modelConfig: default-model
    tools:
      - type: McpServer
        mcpServer:
          name: k8s-tool-server
          kind: RemoteMCPServer
          apiGroup: kagent.dev
          toolNames:
            - k8s_get_resources
            - k8s_describe_resource
            - k8s_delete_resource
            - k8s_apply_manifest
          requireApproval:
            - k8s_delete_resource
            - k8s_apply_manifest

There's also a built-in ask_user tool every agent can call to ask a structured question (single-select, multi-select, free-text). That one is model-initiated ("I need clarification"). requireApproval is tool-initiated ("this tool needs sign-off before it runs"). Use them together.