How is auth handled for deployed agents?

[AnasSahel]

Hey, been playing with flue this week — really like what you're building.

Quick question on something I wanted to make sure I wasn't missing: when I deploy an agent, the endpoint looks like it's reachable without any auth. I had a look around to double-check — nothing about it in the docs, and as far as I can tell no check on the request path in the source either. If I'm wrong about that, just point me to the right place and feel free to close.

Assuming it's not there yet, I figured it was worth raising. A few things stood out to me as a user:

• the agent runs on my own LLM keys, so any traffic costs me money
• tools are usually wired to my creds (DB, APIs, files), so a caller acts with my permissions
• deploy URLs end up in surprising places — screenshots, bug reports, browser history

I saw PR #52 brings in flue.config.ts, which felt like a natural place to wire something minimal. Even a shared-secret env var as a default, plus a hook for people who want to plug in their own auth (JWT, OAuth, IP allowlist), would already cover a lot of ground.

Would love to hear how you're thinking about this.

[tunnckoCore]

For now, maybe put an auth proxy in front? Deployed URLs are not necessarily the right thing to share anyway? 🤔

Tho, we maybe really need to some sort of access to the generated server, maybe a "pre-request" hook exposed through the Flue Config? @FredKSchott

[FredKSchott]

Copying over response from #54

Lets keep this issue open to explore more.

---

• this server is not currently optimized to be openly accessible from your users, generally, to hit directly from the browser.
• BUT, if you were to do that, it would be your responsibility to add secure handling inside of the handler to verify that the requesting user had access to run that handler. We may need to beef this up a bit, though. For example I don't know if the handler has enough information passed to it to properly protect each route (ex: doesn't get headers, to check Authorization header).

The other useful feature that is currently missing would be the ability to control the application entrypoint, like middleware or a app.ts/server.ts entrypoint that you'd control. There would be more clear that you'd have access to headers and such.

Closing this issue as incorrect though, it's framed as a security vulnerability and we don't consider this a vulnerability of the framework, just something you need to keep in mind when building with Flue, the same as if you were building any other server.

I'll spin up issues/discussions for those other improvements mentioned, to track.

[AnasSahel]

Thanks Fred — that clarifies the posture. The framing on my end probably came out tighter than I meant: the bullets were really use-case context, not a threat model. Whichever direction feels right to you — secure-by-default, or giving people the surface area to handle it themselves — works for me. Mostly I just wanted to flag the question.

The piece that caught my eye is the one about the handler not currently seeing the request headers. That feels like the natural unlock — once headers are in scope, anyone already running an auth service (Auth0, Clerk, Supabase, a homegrown JWT issuer) can verify a token in-handler and move on. Which actually lines up cleanly with the posture you described: the handler stays where access decisions happen, it just has enough information to make them.

I'll keep an eye out for the middleware / app.ts thread when you spin it up.