Agno 2.6.7 Adds User Isolation and URL Fetch Guardrails Because Agent Platforms Are Becoming Multi-Tenant Web Apps

Agno’s v2.6.7 release is a useful reminder that “agent framework” has become too small a phrase for what these projects are building. Once a system stores sessions, memories, traces, approvals, knowledge, workflow runs, and user-facing APIs, it is not just an SDK. It is a multi-tenant web application with a model attached. That means it inherits the same old obligations: isolate users, constrain server-side fetches, preserve audit identity, and do not let convenient defaults become production liabilities.

The release brings three changes that belong in the same sentence: opt-in per-user data isolation for AgentOS authenticated endpoints, allowed_hosts URL-fetch guardrails for knowledge readers, and a new experimental GeminiInteractions model class for Google’s stateful Interactions API. It also fixes trace identity overwrite when child agents share a trace with a parent team. The headline feature may depend on who is reading, but the underlying story is clear: Agno is becoming platform infrastructure, and platform infrastructure does not get to hand-wave boundaries.

Agno’s docs describe it as an SDK to “build, run, and manage agent platforms,” with 50+ production API endpoints using SSE and websockets, storage for sessions, memory, knowledge and traces, 100+ integrations, context providers, human approval, OpenTelemetry tracing, JWT-based RBAC, and multi-user or multi-tenant isolation. Those are not toy-framework claims. They are backend claims. Version 2.6.7 is interesting because it tightens the backend parts.

JWT auth is not the same as user isolation

The largest change is PR #7606, which adds opt-in per-user data isolation across AgentOS authenticated endpoints. The flag is explicit: AuthorizationConfig(user_isolation=True). When enabled, non-admin JWT callers are constrained to data owned by the JWT sub for user-scoped resources, including sessions, memories, traces, approvals, and agent, team, or workflow run lookups. Admin users keep an unscoped operator view.

The important detail is that this is not enabled by default. Existing authorization=True deployments keep JWT validation and RBAC without changing shared-data behavior. That is a defensible compatibility decision, especially for teams that built assumptions around the previous model. It is also a footgun if operators casually equate “we turned on auth” with “users cannot see each other’s data.” Those are different properties.

This distinction matters because agent platforms create unusually messy ownership. A normal SaaS app usually has a clean primary resource: a document, ticket, repo, invoice, or project. Agent systems accumulate sessions, memory entries, trace spans, approval requests, tool outputs, and workflow runs. Some are user-scoped, some are team-scoped, and some are operator-scoped. If the access model is not explicit, leaks do not necessarily look like obvious database bugs. They look like a user seeing a trace, approval, or memory artifact that “felt internal” but was never properly scoped.

For practitioners, the migration should be deliberate. If AgentOS backs a product with multiple users, enable user_isolation=True in a staging environment and test the boring matrix: non-admin user A cannot read user B’s sessions, memories, traces, approvals, or run lookups; admin users can perform operator review; team and workflow resources match your actual product model; and any custom endpoints preserve the same ownership rules. Do not stop at login working. Login working is table stakes. Isolation working is the feature.

Knowledge ingestion is an HTTP client with consequences

The second major hardening change, PR #7892, extends allowed_hosts SSRF protection to knowledge readers. The PR describes an unauthenticated SSRF path in POST /knowledge/content, where attacker-controlled URLs could be fetched by the server and stored in the searchable vector store. The fix extends opt-in allowlisting beyond earlier LLMsTxtReader hardening to every reader that fetches attacker-influenceable URLs.

This is one of the cleanest examples of why agent security is often ordinary web security with more confusing trigger paths. A knowledge reader sounds harmless because it “just ingests content.” But if a user, prompt, or agent-controlled workflow can influence the URL, the reader becomes a server-side HTTP client exposed to untrusted input. That is SSRF. The classic targets still apply: http://127.0.0.1:8000/admin, internal services, cloud metadata endpoints such as http://169.254.169.254/latest/meta-data, and any endpoint reachable from the server but not the attacker’s machine.

The agent twist is that prompt injection can become URL selection. A model reading hostile content may be convinced to fetch “helpful” follow-up URLs. A tool that imports docs can be steered toward private infrastructure. A workflow intended for documentation ingestion becomes an internal network scanner with a polite name. Host allowlists are not elegant, but they are the right default shape. If the workflow is supposed to ingest docs from docs.agno.com, say that. Do not give the model the whole network and hope it behaves.

Teams using Agno should inventory every reader or tool that fetches URLs, then set allowed_hosts according to the actual business purpose. They should also review redirect behavior, because allowlists that validate only the first URL can be bypassed by a friendly-looking domain that redirects somewhere less friendly. The broader rule: any URL fetched by the server because an agent, user, or document suggested it is untrusted input until proven otherwise.

Traces are evidence, so they have to stay truthful

Agno also fixes trace identity overwrite when a child agent’s spans share a trace_id with a parent Team. The bug came from reversed COALESCE order in upsert_trace and fallback root-span selection that could treat the first child span as root when no true root existed. The practical result was trace metadata such as session_id, agent_id, or team_id being clobbered.

That may sound like observability bookkeeping. It is more than that. In agent systems, traces are evidence. They answer who initiated the workflow, which agent acted, which tools ran, which approvals were required, what failed, and what should be billed or audited. If a child span can overwrite parent identity, your trace store starts telling partial lies. Debugging gets harder, but so does governance. Post-incident review depends on hierarchy being preserved, not flattened into whichever span wrote last.

Multi-agent systems especially need trace models that represent parent-child relationships without losing ownership. If a team agent delegates to a child agent, operators need to see both the delegation and the boundary. The child should not erase the team. The team should not hide the child. That sounds basic because it is basic; basic things become product risk when frameworks move from examples to hosted runtimes.

The forward-looking feature is GeminiInteractions, which uses Google’s experimental Interactions API rather than the usual generateContent flow. The PR says it supports server-side conversation history via previous_interaction_id, implicit caching, typed execution steps such as text, function_call, and thought, plus background execution for long-running tasks like Deep Research. It requires google-genai>=1.55.0 and is explicitly experimental.

This is worth watching because it changes the runtime model. Stateless generation APIs force frameworks to resend history, reconstruct state, and infer execution structure from responses. Server-side interaction state and typed steps could reduce token overhead and produce cleaner execution records. But experimental means experimental. Use it behind a feature flag, compare traces and cost behavior against your existing Gemini path, and avoid making it the foundation for a production workflow until the API shape settles.

The concrete checklist for Agno users is refreshingly unromantic: enable user_isolation=True for multi-user AgentOS deployments; test admin and non-admin access paths; set allowed_hosts on URL-fetching knowledge readers; audit unauthenticated knowledge ingestion endpoints; verify multi-agent traces preserve parent and child identity; and treat GeminiInteractions as a test surface, not a default dependency.

The broader take is that Agno is growing into the category it claims: an agent platform. That is good. It also means the platform must meet the same bar as any serious backend. User isolation, SSRF guardrails, and truthful traces are not “agent safety features.” They are table stakes for software that lets agents operate around user data and internal systems. The industry keeps trying to make agents sound magical. Releases like this are more useful because they make them sound accountable.

Sources: Agno v2.6.7 release, AgentOS user isolation PR, knowledge reader allowed_hosts PR, GeminiInteractions PR, trace identity fix PR, Agno documentation