Agent Frameworks vs Managed Agent Platforms: Who Owns Security

Choosing between an open-source agent framework and a managed agent platform is mostly a decision about who runs the security controls, yet teams usually make it on developer convenience alone. With a framework you own the whole stack: the process the agent runs in, the credentials it holds, the sandbox for generated code, the logs and every dependency. With a managed platform the provider runs the runtime, isolation and much of the identity plumbing, but you still own permissions, tool design, data exposure and how the agent behaves. This guide sets out that split control by control, the threat model and failure modes of each option, how platform features can lock your controls in, and decision criteria by team maturity and data sensitivity, with a worked scenario. It is for security architects, AI platform owners and engineering leads deciding where agents should run.

Key takeaways

• A framework is a library, a platform is a service. A framework runs inside your process with your identity and your defaults; a managed platform hosts the agent loop and offers identity, isolation, policy and tracing as configurable services.
• Managed does not mean secured for you. Microsoft's AI shared responsibility guidance states that security responsibilities generally sit with the party that performs the task, and providers often expose controls as configuration options that you must turn on.
• Frameworks concentrate supply chain risk in your build. Every framework release, integration package and community tool lands in your dependency tree and your patch queue.
• Platforms concentrate control in the provider's model. Agent identities, tool policies and traces written in a provider's format do not move easily, so keep the authoritative policy and evidence in places you control.
• Decide per agent, not per organisation. Data sensitivity, autonomy and your team's ability to run sandboxes and patch dependencies should pick the option, and many estates will run both.

The short answer

Use a managed agent platform when you want the provider to operate runtime isolation, session separation, credential brokering and telemetry, and you can accept its identity model and regions. Use a framework on your own infrastructure when you need control the platform does not give you (custom isolation, on-premises data, specific network paths) and you have the engineering capacity to run the controls a platform would otherwise supply. In both cases the agent's permissions, the design of its tools and the data it can reach remain yours. The two are not exclusive: the platforms covered below host agents written in open-source frameworks, so the real choice is often "framework on our runtime" versus "framework on a provider runtime".

Frameworks and managed platforms side by side

Low-code agent builders sit at the far managed end and are covered in the Low-Code Agent Platforms Guide and not repeated here.

Who owns which control

"Shared" means the provider supplies a mechanism and you must configure and verify it.

Microsoft's shared responsibility guidance for AI describes the same pattern in three layers (AI platform, AI application and AI usage) and notes that responsibilities change with SaaS, PaaS and IaaS delivery. A managed agent platform is a PaaS: the provider takes the platform layer, while the application layer, including tools, grounding data and plugins, stays with you.

Threat model for each option

Framework on your own infrastructure

Architecture in words: a container or function runs your code; your code imports the framework, calls a model API with a key or federated token, executes tools in-process or over MCP, and writes state to a database you run. Everything the agent can reach is decided by that workload's identity and network position.

• Dependency compromise: a malicious or vulnerable framework, integration or tool package executes with the agent's privileges. OWASP LLM03:2025 Supply Chain and the OWASP Top 10 for Agentic Applications entry ASI04 Agentic Supply Chain Vulnerabilities both cover this.
• Unsafe defaults and state: local code executors and deserialised checkpoints turn model output or stored data into code paths. The Securing Agent Frameworks Guide lists the specific settings and CVEs.
• Secrets in the process: model and tool keys in environment variables are readable by any code the agent runs.
• Exposed builder or admin surfaces: self-hosted visual builders and tracing UIs are internet-facing applications in their own right.

Managed platform

Architecture in words: you register an agent definition or push a container; the provider runtime starts an isolated session per conversation, issues or assumes an identity, calls tools through its gateway or connectors, stores sessions and memory in its services and emits traces to its monitoring. You configure, the provider operates.

• Over-broad platform identity: a project-level managed identity shared by every agent means one hijacked agent has every agent's reach. This maps to ASI03 Identity and Privilege Abuse.
• Configuration drift and unused controls: policy services, private networking, customer-managed keys and tracing usually need to be switched on; defaults may favour getting started.
• Provider-side incidents: credentials and infrastructure the provider runs are outside your view. Your mitigation is contractual assurance, short-lived credentials and blast radius limits, not configuration.
• Shared memory and sessions: memory stores shared across agents or users can leak or be poisoned across boundaries. See the AI Agent Memory Security Guide.

Both options share one root threat: untrusted text steering an agent with real permissions. Hosting does not change that; permission design does.

What the major managed platforms document

Platforms are listed alphabetically; the order is not a ranking. Each row gives the provider's own feature names from its documentation as checked in November 2026. Deep configuration for each sits in its own NHI Mgmt Group guide.

Availability: Amazon Bedrock AgentCore documents its services by Region. Google Cloud documents CMEK for deployed agents on single-region endpoints, not the multi-regional endpoints. Microsoft marks hosted agents and workflow agents as preview, and documents private networking for prompt and workflow agents. Confirm current status before you design around a feature.

See the AWS Bedrock AgentCore Security Guide, the Vertex AI Agent Engine security guide and the Microsoft Foundry Agent Service Security Guide.

Supply chain exposure of frameworks

A framework is rarely one package. A typical agent pulls a core library, a graph or orchestration runtime, provider integrations, vector store clients, document loaders, MCP adapters and community tools, each with its own release cadence. Controls:

1. Pin and lock: lock files with hashes for every transitive dependency, built in CI from a private mirror; no unpinned installs at container start.
2. Minimise integrations: install only the provider and tool packages the agent uses. Each extra loader or tool is code that runs with the agent's credentials.
3. Track advisories per package: subscribe to the framework's security advisories and its vulnerability disclosure channel; LangChain, for example, documents a vulnerability disclosure programme and a security contact.
4. Review community tools as code: treat prompt hubs, shared tools and MCP servers as third-party software with an owner and a review.
5. Produce an AI-BOM: record framework versions, models and tools per agent. See the AI Supply Chain and AI-BOM Guide.

Moving to a platform does not remove this risk when you deploy your own framework code as a hosted agent: the provider patches its runtime, but your container still carries your dependency tree.

Platform lock-in of controls

For security, lock-in matters because controls written in one provider's model must be rebuilt to move, and rebuilt controls are often weaker.

• Identity: platform agent identities are bound to that provider's IAM. Keep the agent register (owner, purpose, data classes, autonomy level) in your own inventory and treat the platform identity as one attribute. See the AI agent registry.
• Policy: tool policies in a provider's policy service are enforced only for traffic through that provider's gateway. Write policies in a portable language where the platform supports it, keep them in version control, and enforce critical checks again inside the tool or API.
• Telemetry: prefer OpenTelemetry export to your own SIEM or data lake so evidence survives a migration and meets your retention rules.
• Protocols: exposing tools through MCP and agent-to-agent traffic through A2A, which several platforms support, keeps tool and agent interfaces portable.
• Memory: long-term memory in a provider store may not export cleanly; decide early what is retained and where.

Failure modes compared

Decision criteria by team maturity and data sensitivity

Small versus large organisations: smaller organisations usually gain more security from a platform because the controls they would otherwise build are the ones they are least likely to run well. Large organisations often need both, with a platform as the default and a reviewed framework pattern for cases with special data or network needs, and the same identity, registry and logging standards across both.

Worked scenario: an invoice reconciliation agent

A finance team wants an agent that reads supplier invoices from a shared mailbox, matches them to purchase orders in the ERP and drafts payment batches for approval. Data is commercially sensitive; payments are high impact.

1. Threat model: invoices are untrusted input and can carry injected instructions. The highest-impact tool is "create payment batch".
2. Option A, framework on own infrastructure: the team must build a credential-free parsing step, issue a workload identity scoped to read purchase orders and write draft batches only, instrument tracing, and maintain the framework and mail integration packages. Approval is a graph interrupt before the batch tool.
3. Option B, managed platform: the team registers the agent with its own platform identity, connects the ERP through the platform gateway with a policy that allows only draft creation, enables tracing and exports it, and uses the platform's isolated session for document parsing.
4. What does not change: in both options the ERP role allows drafts only, a human approves payment release in the ERP itself, and the mailbox reader cannot reach the payment tool in the same context.
5. Decision: with no platform engineering team and residency met by the provider's region, the team chooses the platform, keeps the policy in version control and exports traces to its SIEM to limit lock-in.

Where identity fits

Whichever option you choose, each production agent is a non-human identity with an owner, a purpose and a lifecycle. On a framework that identity is your workload identity; prefer federation over static keys, as set out in the Workload Identity Federation Guide. On a platform it is the provider-issued agent identity. In both cases separate the agent's own identity from any user it acts for, and use on-behalf-of tokens where it acts for a user. See the Agentic AI Identity Guide.

Detection and measurement

Monitor the same signals regardless of hosting: tool calls by agent identity, denied policy decisions, new tools or MCP servers attached, changes to agent definitions and identities, sandbox egress attempts, and token use outside the agent's normal pattern. On a platform, also alert on disabling of tracing, policy or private networking settings through the provider's control-plane audit log.

• Identity coverage: percentage of production agents with a dedicated identity and named owner (target 100%).
• Evidence coverage: percentage of agents whose traces reach your SIEM with defined retention.
• Policy coverage: percentage of high-impact tools behind an enforced policy or approval step.
• Patch latency: days from a framework or SDK security release to redeployment of affected agents.
• Static secret count: number of long-lived keys held in agent configuration or environment variables (trend to zero).
• Portability check: share of tool policies stored in version control outside the platform.

Framework mapping

Common failure patterns

• Treating a self-hosted builder as an internal tool: agent builders hold provider keys and connection strings. In the Langflow CVE-2025-3248 exploitation 2025, unpatched internet-facing servers had their environment variables dumped; owning the stack means owning its patching and exposure.
• Assuming the provider's credentials are your control: in the CrewAI "Uncrew" flaw 2025, an error from a hosted provisioning check exposed an internal token, and the provider fixed it within hours of the report. Customers cannot configure that away; they can ask about secret handling in due diligence and keep the credentials they hand a platform short-lived and narrow.
• One managed identity for every agent: convenient at setup, it removes attribution and multiplies blast radius.
• Leaving platform controls off: tracing, policy and private networking that are documented but never enabled give a false sense of coverage.

Practitioner checklist

• Fill in the control ownership table for each production agent and get the platform or engineering owner to sign it.
• Give every agent its own identity and owner, on either option, and record it in your agent register.
• Remove static keys from agent configuration; use federation, credential providers or on-behalf-of tokens.
• Run generated code only in a credential-free sandbox with egress restricted.
• Enforce tool policy at an enforcement point, store policies in version control, and check high-impact actions again in the target system.
• Turn on tracing, export it to your SIEM, and set redaction and retention.
• Lock and scan framework dependencies, including those inside containers you deploy to a platform.
• Confirm region, preview status and customer-managed key support for every platform feature you depend on.

Standards and references

• Microsoft Learn: Artificial intelligence (AI) shared responsibility model
• NCSC: Guidelines for secure AI system development
• OWASP: Top 10 for LLM Applications 2025
• OWASP: Top 10 for Agentic Applications for 2026
• AWS: What is Amazon Bedrock AgentCore
• Google Cloud: Gemini Enterprise Agent Platform, Agent Runtime
• Microsoft Learn: Foundry Agent Service overview
• LangChain: Security policy

Related NHI Mgmt Group resources: Securing Agent Frameworks Guide · Low-Code Agent Platforms Guide · Agent Frameworks vs Workflow Orchestration · AI Agent Sandboxing and Code Execution Guide · Agent platform RFP template