Many AI SDKs and agent frameworks get built and marketed primarily around capability, how quickly a developer can get an impressive demo running, rather than around secure defaults. That's a reasonable product priority for a framework vendor competing on developer experience, but it means adopting one of these frameworks without a specific security review often means inheriting whatever default posture the framework ships with, which can be a lot more permissive than your organization's actual security requirements.
Understand what the framework does by default for tool authorization
Ask specifically what the framework does, out of the box, when an agent built with it wants to call a tool: does it require explicit configuration of authorization logic, or does it default to executing any tool call the model requests with no authorization check unless the developer deliberately adds one. Frameworks optimized for quick prototyping often default to the latter, a reasonable default for a quick demo and a dangerous one for a production system if the developer never explicitly overrides it with real authorization logic.
Check how the framework handles untrusted content by default
Review whether the framework provides any built-in structure for separating trusted instructions from untrusted content, following the instruction hierarchy covered in prompt security guidance, or whether it leaves this entirely to the developer with no framework-level support or guidance at all. A framework with no built-in concept of trusted versus untrusted content dumps the full burden of this critical distinction on each individual developer using it, which raises the odds of inconsistent implementation across a team.
Review how the framework handles agent loop iteration by default
For agentic frameworks specifically, check whether there's a default limit on how many iterations or tool calls an agent can make within a single task, and how easy it is to configure that limit. A framework with no default limit, or an extremely high one, can let a runaway agent burn through far more resources than intended before a developer even realizes a limit needs explicit configuration, covered in rate limiting guidance elsewhere.
Examine the framework's own dependency chain
Following supply chain risk guidance, review the framework's own dependencies for known vulnerabilities and general maintenance health, the same due diligence you'd apply to any software dependency. A newer, rapidly-evolving agent framework can have far less mature dependency management practice than an established conventional software library, and that deserves direct evaluation, not an assumption based on the framework's popularity or how impressive its demos look.
Check what the framework logs by default and where that data goes
Review what the framework captures in logs by default, whether that includes full prompts and responses, and where that logged data ends up, particularly if the framework includes any built-in telemetry or analytics feature sending data to the framework vendor. This connects to the privacy-preserving logging guidance covered elsewhere, and a framework default that sends prompt content to a third party for telemetry purposes needs explicit review and likely explicit disabling if that behavior isn't acceptable for your organization's data handling requirements.
Test the framework's actual behavior, not only its documentation
Documentation describing a framework's security features can describe intended behavior that doesn't always match actual implementation, particularly for newer or rapidly evolving frameworks. Test the specific security-relevant behaviors directly, does an unauthorized tool call actually get blocked when the documented authorization feature is configured, rather than trusting documentation claims with no direct verification.
Establish an internal secure configuration standard for adopted frameworks
Once a framework is selected, document an internal standard for how it must be configured for security-relevant behavior within your organization, explicit authorization logic required, specific iteration limits set, telemetry disabled if it's not acceptable, so every team adopting the framework internally starts from a consistent, reviewed secure configuration instead of each team independently discovering and patching the framework's default gaps on their own.
Reassess when the framework is updated significantly
Framework updates can change default behavior, sometimes improving security defaults and sometimes introducing new capability with a permissive default that wasn't there before. Reassess your internal secure configuration standard against significant framework version updates, rather than assuming a configuration validated against an older version stays fully applicable to a newer one without review.
Where TELEON fits
Regardless of which agent framework a team adopts, TELEON's policy enforcement, applied through the gateway or supported middleware, can provide an authorization backstop at the tool-call boundary that does not depend on the framework's own default posture, reducing how much risk a permissive framework default actually introduces in practice.
Reviewing framework documentation, testing actual behavior, and establishing an internal secure configuration standard remain evaluation work that has to be done directly by the team adopting a specific framework.
A short checklist
- Check the framework's default tool authorization behavior explicitly.
- Check whether the framework provides built-in support for trusted
versus untrusted content separation.
- Check the default agent loop iteration limit and how it is configured.
- Review the framework's own dependency chain for supply chain risk.
- Check default logging behavior and any third-party telemetry.
- Test actual security-relevant behavior directly, not only
documentation claims.
- Document an internal secure configuration standard for adopted
frameworks.
- Reassess the standard against significant framework version updates.
Security review of AI SDKs and frameworks matters because many are optimized for fast, impressive prototyping rather than safe production defaults, and adopting one without reviewing its actual default behavior means inheriting whatever permissiveness the framework ships with by default.