Mastra and the agent framework race are reshaping AI tooling

At a glance

What this is: This is a discussion of Mastra’s open-source AI agent framework and the direction of the agent tooling ecosystem, with the key finding that production teams want familiar developer workflows rather than a new stack.

Why it matters: It matters because agent frameworks are becoming part of identity and access design, forcing IAM, NHI, and platform teams to decide how autonomous runtime behaviour is governed inside existing application estates.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read WorkOS's interview on Mastra, AI agent frameworks, and the future of agentic tooling

Context

AI agent frameworks are not just developer productivity tools. They shape how autonomous workflows are built, which in turn shapes how identities, tools, and data are reached at runtime. For IAM teams, the practical question is whether the framework makes governance visible or hides it inside application logic.

The TypeScript choice is less about language preference than operational fit. By aligning with existing web application stacks, the framework lowers adoption friction, but it also raises a familiar identity problem: once agents are embedded in production apps, access boundaries can become as fluid as the code that creates them.

Key questions

Q: How should security teams govern AI agents built into application frameworks?

A: They should treat the framework layer as part of the identity architecture, not just the app stack. That means defining ownership, scoping tool permissions, separating memory from authority, and reviewing every production agent path as a governed non-human identity rather than an informal extension of the application.

Q: Why do agent frameworks create new access-risk problems for IAM teams?

A: Because they let runtime decisions, tool calls, and stateful workflows happen inside familiar development stacks, which can hide where authorisation actually occurs. When identity is embedded in code and orchestration, access can expand faster than governance can explain or certify it.

Q: What breaks when AI agent permissions are inherited from the host application?

A: The boundary between application access and agent access disappears. That makes it difficult to prove least privilege, trace tool usage, or revoke access cleanly when the agent is retired or repurposed, especially if secrets and memory are reused across workflows.

Q: How can teams reduce risk when building autonomous workflows in TypeScript?

A: They should require explicit identity ownership, short-lived credentials, reviewed integrations, and a clear offboarding path for each agent. The goal is to prevent autonomous workflows from accumulating persistent access simply because they are convenient to build and reuse.

Technical breakdown

TypeScript agent frameworks and identity integration

TypeScript-based agent frameworks package the infrastructure needed to run agentic workflows inside the application stack developers already use. That usually includes tool calling, state handling, workflow composition, and model integration, so the application can orchestrate agent actions without a separate service boundary. From an identity perspective, that matters because the framework becomes the place where credentials, permissions, and data access are bound to runtime behaviour. If governance is not explicit at that layer, access control can be inherited implicitly from application code, which is harder to review and audit.

Practical implication: treat the framework layer as an identity control point, not just an application abstraction.

Memory, structured workflows, and runtime access boundaries

Memory in agent frameworks is not the same as human memory. It is persisted context that can influence future tool use, prompt selection, and decision paths across sessions or steps. Structured workflows add guardrails, but they can also conceal where the actual authorisation decision is made if every step inherits broad access from the host application. For security teams, the key issue is whether the framework preserves a clear boundary between remembered context and authorised action, or whether prior state quietly expands what the agent can do next.

Practical implication: review where memory state can alter access decisions or tool selection across sessions.

Why agent ecosystems create governance pressure

Agent ecosystems tend to evolve faster than the governance model around them. As more teams build reusable primitives for autonomous workflows, the risk is not just more agents, but more places where non-human identities are created without a matching lifecycle process. That creates hidden variance in how tools, secrets, and external services are invoked. The technical challenge is therefore not only framework design, but whether identity governance can keep up with the rate at which runtime autonomy is being embedded into ordinary application development.

Practical implication: require lifecycle ownership and access review for every production agent path, even when it is built into the app stack.

Threat narrative

Attacker objective: The attacker objective is to exploit agent runtime access and turn embedded workflow permissions into unauthorized tool use, data access, or downstream system compromise.

1. Entry begins when developers embed agent frameworks directly into production TypeScript applications, giving the agent a normal application foothold and access to the same integration points as the host app.
2. Credential access or abuse occurs when the framework is allowed to call tools, models, or external systems through broadly scoped secrets and inherited application permissions.
3. Impact follows when the agent can reach business workflows, data stores, or external services without a distinct identity boundary, making misuse or overreach hard to distinguish from legitimate execution.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

TypeScript agent frameworks are becoming identity infrastructure by accident. When developers build autonomous workflows inside the same language and deployment stack as the application, the framework starts acting like an identity control plane whether teams label it that way or not. That shifts governance from a narrow tooling question to a broader IAM and NHI design problem. Practitioners should treat the framework boundary as part of access architecture, not just code structure.

Autonomous workflows change the trust model for non-human identity. The useful unit is no longer the service account alone, but the combination of code, memory, tool access, and execution timing that the framework orchestrates. That means traditional provisioning assumptions can miss where authority is actually exercised. IAM teams should reassess where identity ends and runtime autonomy begins.

Agent framework adoption is a signal that lifecycle governance is moving into the build layer. Once a framework makes autonomous workflows easy to assemble, the creation of non-human identities becomes faster than the surrounding review and offboarding process. That widens the gap between runtime access and governance visibility. Practitioners should expect more shadow NHI if framework sprawl is not tied to lifecycle ownership.

Identity blast radius is the right concept for agent frameworks. The issue is not only whether an agent can act, but how far its permissions can spread when tool calling, memory, and integrations are composed in one execution path. That makes the blast radius of a mistake or compromise larger than a single credential. Security teams should map where one agent path can touch multiple systems without a separate review boundary.

Agent ecosystem maturity is exposing a familiar control failure: access is being granted faster than it can be explained. That is the core governance tension in production AI workflows, and it applies across NHI, platform engineering, and IAM. If no one can clearly describe why a runtime identity has a given privilege, the programme has already lost the audit trail. Practitioners should demand explicit authority mapping before scale arrives.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• For a broader governance baseline, see Top 10 NHI Issues for the control gaps that show up first when identity sprawl outpaces policy.

What this signals

Identity blast radius is becoming the more useful planning concept for teams building agentic workflows. When a framework can compose tool calls, memory, and integrations in one execution path, the question is not only whether access exists, but how far one agent can move before governance notices. That is why agent identity design now belongs in architecture review, not just in application delivery.

With 98% of companies planning to deploy even more AI agents within the next 12 months, per the AI Agents: The New Attack Surface report, the governance problem is scaling faster than the review model. Teams should expect more hidden non-human identities unless every new agent path is tied to lifecycle ownership and audit visibility.

The practical signal to watch is whether the organisation can explain, in plain language, why a given workflow has the permissions it has. If that answer depends on inherited application access or a developer’s informal judgment, the programme has already moved beyond manageable NHI sprawl. Pair that review with the OWASP NHI Top 10 for a control-oriented lens on agentic application risk.

For practitioners

• Map agent framework trust boundaries Document where the framework creates, stores, and reuses credentials, tool permissions, and memory state so identity review can happen at the same layer as runtime execution.
• Assign ownership to every production agent path Tie each autonomous workflow to a named system owner, a review cadence, and an offboarding trigger so non-human identity does not persist after the business use case changes.
• Separate remembered context from authorised action Review whether stored memory can influence access to tools or data, and require explicit authorisation points when prior state changes the agent’s decision path.
• Limit inherited application permissions Avoid letting agent workflows inherit broad host-application access by default. Scope secrets, API keys, and service permissions to the smallest execution path that can function safely.

Key takeaways

• AI agent frameworks are becoming governance objects, not just developer tools, because they embed identity, memory, and tool access into runtime workflows.
• The risk is less about language choice and more about access concentration, since a single agent path can inherit broad permissions across multiple systems.
• IAM teams should review agent ownership, permission scope, and offboarding before framework adoption turns convenience into persistent identity sprawl.

Key terms

• Agent Framework: An agent framework is a software layer that helps developers build, coordinate, and run AI agents or workflows. In practice it can concentrate tool access, memory, and execution logic, which makes it a governance boundary as much as a developer convenience layer.
• Runtime Identity Boundary: A runtime identity boundary is the point where a system’s authorised access stops and another actor’s access begins. For autonomous workflows, that boundary must be explicit, because the agent may call tools, reuse memory, and chain actions inside a single session.
• Identity Blast Radius: Identity blast radius is the amount of access and downstream system reach created when one identity or workflow is over-scoped. In agentic environments, it measures how far a single tool call, secret, or workflow can spread before governance can intervene.
• Memory-Driven Access: Memory-driven access is when prior conversation state, stored context, or persisted workflow memory influences what an agent can do next. That is useful for continuity, but it becomes a governance issue if remembered state changes authority without an explicit review point.

Deepen your knowledge

AI agent framework governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your teams are embedding autonomous workflows into production applications, this course helps connect runtime design to identity control.

This post draws on content published by WorkOS: Abhi Aiyer on building Mastra and the future of AI agent frameworks. Read the original.