feat: support gateway token passthrough for embedded controllers by codyhartsook · Pull Request #3263 · kagent-dev/kagent

codyhartsook · 2026-10-19T05:08:14Z

Lets an embedding controller deliver tokenPassthrough credentials at the egress gateway, through app.Options.EgressPolicyCompilers. Builds on #3177 and #3257.

Revisions record each passthrough client as a target {origin, header, prefix} on egress Access.
token_passthrough_targets replaces token_passthrough_origins in the unreleased baseline migration.
Compilers run in order after the built-in EgressPolicy compiler and may change the policy. Kagent then validates it.
With any compiler registered, every target must be bound.
If a compiler or the validation fails, the actor gets no egress until a retry succeeds.
The embedder's UpstreamAuth must swap the caller token for the kagent-credential-injected placeholder, which the ADK forwards.
Covers Go ADK MCP and models, and Python OpenAI/Anthropic models. Claude, Codex, Python MCP, Ollama and Bedrock are follow-ups.

Behavior change with no compiler registered:

A passthrough origin can't be shared with MCP or model clients that don't opt in, or with an explicit header matching a target.

The Migration Immutability check fails because this edits 000001_initial.sql, as that file's header allows until the 1.0 release.

Testing: the affected race suites and the migration and PostgreSQL round-trip tests pass locally, and CI lint passes.

EItanya · 2026-10-19T15:42:38Z

🤖 AI-generated review.

I think this is putting the extension behavior too high in the stack. The use case is that we want different behavior on the compiled Substrate EgressPolicy for specific tokenPassthrough origins. However, this threads a provider name through app, the controller, the generic translator, and every harness compiler, then hardcodes the provider URI format in credential compilation.

Could we make EgressPolicy compilation extensible instead? I'm thinking of a simple ordered compiler chain:

type EgressPolicyCompiler interface {
    Compile(context.Context, EgressPolicyInput, *ateapipb.EgressPolicy) error
}

The OSS compiler would always run first and build the normal allowlist and credential effects. Embedded controllers could register additional compilers that run afterward and add their behavior for the relevant origins. The chain would validate the final policy and reject conflicting effects rather than using last-writer-wins.

That would let the generic compilation path keep tokenPassthrough as semantic, origin-scoped information, while the vendor compiler decides how that becomes an EgressPolicy effect. It also gives us a reusable backend extension point without making Claude, Codex, ADK, models, or MCP compilation know about a particular provider or URI protocol.

With that boundary, I don't think we need TokenPassthroughProvider or most of the provider-specific translator and harness changes in this PR.

Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

EItanya · 2026-10-19T19:58:21Z

+		return egress.Access{}, nil, err
 	}
-	return egress.EffectiveAccess(base, grants, row.TokenPassthroughOrigins)
+	return access, targets, nil


should passthrough targets be a part of access?

Yeah, makes sense. I kept them separate because targets are pinned to the revision, but they can live on Access

Why are targets pinned to the revision?

so the gateway policy matches the actor’s compiled config, even after the Agent or ModelConfig change

updated so they are on Access

EItanya · 2026-10-19T20:04:04Z

 			// host set the request goes to that host, so api.ollama.com never
 			// needs to be reachable.
-			hasCredential := modelConfig.Spec.APIKeySecret != "" || modelConfig.Spec.TokenPassthrough
+			hasCredential := modelConfig.Spec.APIKeySecret != ""


Ollama doesn’t read the caller token today, so added a validation error for passthrough and removed because its now unreachable. Could split that into a separate fix

I know there's the ability to use ollama cloud, but you're the Ollama client doesn't support passthrough?

🤖 AI assisted response.

Ollama Cloud works with a Secret key, but our Ollama clients never read the caller token. The Go ADK takes the key only from OLLAMA_API_KEY, and the Python ADK ignores api_key_passthrough. So tokenPassthrough on an Ollama model has no effect today. With no key, a cloud model even routes to the local daemon. Supporting it means having the Ollama client use the passthrough token, which I'd do as a follow-up

reverted, I'll address this in a follow up instead

EItanya · 2026-10-19T20:04:33Z

 		}
 		// Populate shared transport settings.
 		populateTLSFields(ollama, model.Spec.TLS)
-		ollama.ApiKeyPassthrough = model.Spec.TokenPassthrough


same reason as above, the ollama runtime never reads this flag. I’ll keep these changes together in a separate fix

EItanya · 2026-10-19T20:04:37Z


 		// Populate shared transport settings.
 		populateTLSFields(bedrock, model.Spec.TLS)
-		bedrock.ApiKeyPassthrough = model.Spec.TokenPassthrough


same issue with Bedrock, the runtime doesn’t use this flag to forward the caller token

EItanya · 2026-10-19T20:08:46Z


+// validCredentialURI accepts ate-secret://<provider>/<path>. Provider names are
+// lowercase DNS names without ports. k8s.io paths name one Secret key.
+func validCredentialURI(raw string) error {


Did this functionality move or did it just get added?

a bit of both. I pulled the existing validation into a helper for clarity and expanded it to allow other credential providers. The k8s.io checks stay intact. Func was getting a bit hard to read

Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

…low-up Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

github-actions Bot added enhancement New feature or request and removed enhancement New feature or request labels Oct 19, 2026

QuentinBisson added a commit to giantswarm/kagent-upstream that referenced this pull request Oct 19, 2026

docs(fork): exit the Claude actor-JWT row with kagent-dev#3263

77dd523

QuentinBisson mentioned this pull request Oct 19, 2026

feat(harness): Claude reaches actor-JWT hosts without the forwarder giantswarm/kagent-upstream#717

Merged

codyhartsook force-pushed the codyhartsook/tokenPassthroughGateway branch from 919ddbf to 447b070 Compare October 19, 2026 15:13

feat: bind tokenPassthrough targets through EgressPolicy compilers

c73cf6a

Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

codyhartsook force-pushed the codyhartsook/tokenPassthroughGateway branch from 447b070 to c73cf6a Compare October 19, 2026 19:27

github-actions Bot added enhancement New feature or request and removed enhancement New feature or request labels Oct 19, 2026

codyhartsook marked this pull request as ready for review October 19, 2026 19:46

codyhartsook requested review from a team and supreme-gg-gg as code owners October 19, 2026 19:46

EItanya reviewed Oct 19, 2026

View reviewed changes

teemow pushed a commit to giantswarm/kagent-upstream that referenced this pull request Oct 19, 2026

docs(fork): exit the Claude actor-JWT row with kagent-dev#3263

e1b69c7

teemow pushed a commit to giantswarm/kagent-upstream that referenced this pull request Oct 19, 2026

docs(fork): exit the Claude actor-JWT row with kagent-dev#3263

a969774

codyhartsook added 3 commits October 19, 2026 13:53

feat: let EgressPolicy compilers change the whole policy

6ccd327

Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

refactor: leave Ollama and Bedrock tokenPassthrough handling to a fol…

c589ef6

…low-up Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

refactor: carry tokenPassthrough targets on egress Access

1a1cad6

Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

codyhartsook requested a review from EItanya October 20, 2026 01:01

fix: deny actor egress when an EgressPolicy compiler fails

eecb838

Signed-off-by: Cody Hartsook <cody.hartsook@solo.io>

github-actions Bot added enhancement New feature or request and removed enhancement New feature or request labels Oct 20, 2026

Conversation

codyhartsook commented Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EItanya commented Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codyhartsook Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codyhartsook commented Oct 19, 2026 •

edited

Loading

EItanya commented Oct 19, 2026 •

edited

Loading

codyhartsook Oct 19, 2026 •

edited

Loading