TL;DR: AI agent frameworks are moving into production, with TypeScript, tool calling, memory, structured workflows, and integrations becoming the core primitives for autonomous workflows according to WorkOS. Mastra’s discussion with WorkOS at HumanX 2026 highlights how the governance challenge is no longer just building agents, but deciding how their identities, access, and runtime actions are controlled once they reach production.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: AI agent frameworks are maturing in TypeScript, with production builders valuing familiar tooling, open source feedback loops, and infrastructure for autonomous workflows.
Why it matters: For IAM and NHI teams, the key issue is that agent frameworks are becoming part of production application stacks, which means identity, authorisation, and runtime control have to be designed in from the start.
Context
AI agent frameworks are moving from experimentation into production application stacks. In this interview, WorkOS and Mastra frame the shift around developer experience, TypeScript adoption, and the infrastructure needed to support autonomous workflows.
The identity governance question is not whether agents can be built, but how their runtime behaviour will be controlled once they can call tools, hold context, and participate in workflows. That changes the problem from application scaffolding to identity and access design for non-human executors.
Key questions
Q: How should security teams govern agentic AI as it moves into production?
A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.
Q: Why do TypeScript-based agent frameworks change identity risk for builders?
A: They change risk because they lower the friction of putting agentic behaviour into the same production stack that already handles user sessions, APIs, and service access. When the agent sits inside familiar infrastructure, teams can accidentally inherit existing trust paths instead of designing a separate control model for non-human execution. The result is faster adoption with less governance maturity.
Q: What breaks when tool calling and memory are not bounded in AI agents?
A: Tool calling and memory become uncontrolled delegation mechanisms when they are not bounded by task scope, execution limits, and review points. The agent can combine prior context with live tool access to keep acting beyond the original intent of the workflow. That turns a framework feature into an authority-expansion path.
Q: How do teams decide whether an AI agent needs human approval?
A: Use the sensitivity of the action, not the cleverness of the model, as the decision point. If the agent can change records, move funds, send external messages, or access regulated data, human approval or an independent policy engine should remain in the path. The more irreversible the action, the less autonomy the agent should have.
Technical breakdown
Why TypeScript changes the agent framework adoption curve
Mastra’s TypeScript bet reflects a practical reality: many production web applications and APIs already live in the JavaScript and TypeScript ecosystem. When agent frameworks align with that stack, teams avoid adding a separate Python service just to introduce agentic workflows. That reduces integration friction, simplifies deployment, and keeps agent logic closer to the systems that already enforce identity, permissions, and observability. The important technical point is not the language itself, but the proximity between agent runtime and the existing enterprise control plane. That proximity makes it easier to embed agent actions into standard build, deploy, and access patterns. Practical implication: evaluate agent frameworks in the same operational context as the application stack they will extend.
Practical implication: evaluate agent frameworks in the same operational context as the application stack they will extend.
Tool calling, memory, and structured workflows as control surfaces
The article describes agent frameworks as handling tool calling, memory, structured workflows, and model integrations. These are not just developer conveniences. Tool calling defines what external actions an agent can take, memory defines what context persists across steps, and structured workflows define how far execution can progress without human interruption. In NHI terms, those are control surfaces around authority, state, and delegation. Once agents can combine these primitives at runtime, governance depends on more than API authentication. It depends on whether access is bounded to the task, the context, and the execution window. Practical implication: treat these runtime primitives as identity-relevant design choices, not just orchestration details.
Practical implication: treat these runtime primitives as identity-relevant design choices, not just orchestration details.
The production question is control, not just capability
The article’s core signal is that agent frameworks are leaving the prototype phase and entering production-minded engineering. That matters because production systems need repeatability, auditability, and bounded authority, while agent frameworks are often sold on flexibility and rapid composition. The tension is familiar from other identity domains: what helps developers move faster can also widen the window for uncontrolled action if identity, privilege, and observability are bolted on later. For autonomous workflows, the design problem is not whether an agent can reason, but how much it can do before a human or policy boundary intervenes. Practical implication: require explicit runtime boundaries before agent frameworks are allowed into production access paths.
Practical implication: require explicit runtime boundaries before agent frameworks are allowed into production access paths.
Threat narrative
Attacker objective: The objective is to gain or abuse delegated runtime authority inside production workflows so actions can be executed at machine speed without effective human review.
- Entry occurs when a production team embeds an agent framework into an existing TypeScript application stack and allows the agent to invoke tools as part of normal workflow execution.
- Credential or authority exposure follows when the agent inherits access to model providers, internal services, or application integrations needed to complete those workflows.
- Escalation happens if the framework allows the agent to combine memory, tool calling, and structured execution without tight task boundaries or approval gates.
- Impact is the ability to carry out autonomous runtime actions inside production systems with insufficiently constrained identity and access controls.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agent frameworks are turning identity design into a build-time decision: once autonomous workflows sit inside the same application stack as production services, identity boundaries cannot be deferred to a later governance phase. The article shows that developers want familiar tooling, but familiarity also means agent authority can inherit existing assumptions about trust, execution, and service access. Practitioners should treat framework selection as an access-model decision, not only an engineering preference.
Runtime primitives are now governance primitives: tool calling, memory, structured workflows, and integrations are the actual levers that determine what an agent can do in production. Those levers map directly to authority, context persistence, and scope of action. If they are not explicitly bounded, the framework becomes a delegation engine rather than a controlled application layer. The implication is that agent governance starts at design time, before the first workflow reaches production.
Familiar language stacks do not remove the identity problem, they relocate it: TypeScript lowers adoption friction for full-stack teams, but the access risk follows the runtime, not the language. The fact that agent frameworks feel native to existing web and API environments makes it easier for organisations to absorb them quickly, sometimes faster than identity review processes can adapt. Practitioners should assume that convenience accelerates exposure as much as deployment.
Delegated runtime authority: this article illustrates how quickly a framework can become a proxy for non-human decision-making when tool access, memory, and execution are composed together. The governance question is no longer whether the application is agentic in concept, but whether the identity model recognises that the framework can act, persist context, and continue without a human in the loop. Teams should map where delegated authority begins and where it stops.
What this signals
Agentic adoption will pressure identity programmes to move from account-centric thinking to workflow-centric thinking: once a framework can call tools, carry memory, and sequence actions, the control point is no longer only the credential. It is the workflow boundary, the approval boundary, and the scope boundary together. Programmes that still treat these as application features will miss where the real governance failure occurs.
TypeScript familiarity can conceal a deeper control gap: teams are more likely to ship agentic features when the framework feels native to the stack they already run. That is useful for delivery speed, but it also means identity review, logging, and authorisation checks must be embedded before production rollout, not retrofitted after an incident.
Delegated runtime authority will become a standard audit question: as AI agents move into production, practitioners should expect more scrutiny over who allowed the agent to act, what it could reach, and how its decisions were bounded. The organisations that prepare early will be the ones that can explain agent behaviour in the language of access, not just the language of engineering.
For practitioners
- Define agent authority before framework adoption Document which tools, APIs, and internal services an agent may call, and tie those permissions to a specific workflow scope rather than a reusable application-level grant.
- Separate runtime context from standing access Treat memory and persisted context as part of the security boundary, especially when the agent can reuse prior state across tasks or sessions.
- Require approval gates for high-risk actions Introduce explicit human or policy checkpoints before an agent can change data, trigger deployments, or invoke irreversible downstream operations.
- Instrument agent activity for audit and review Log tool calls, context changes, and workflow transitions so identity and security teams can reconstruct what the agent did and why.
- Review production rollout paths for autonomous behaviours Assess whether the same deployment pattern used for normal application services is now granting agents access to privileged internal functions.
Key takeaways
- AI agent frameworks are becoming production infrastructure, which shifts the security question from whether agents can be built to how their runtime authority is constrained.
- Tool calling, memory, and structured workflows are governance surfaces because they define what an agent can do, what it can remember, and how far it can go without intervention.
- Teams should treat framework adoption as an identity design decision and set explicit runtime boundaries before autonomous workflows are allowed into production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on how agent frameworks create delegated runtime authority and privilege scope risks. |
| Recommendation — Apply ASI03 to bound agent permissions, tool access, and runtime authority before production rollout. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent frameworks create non-human execution paths that can inherit excessive permissions in production. |
| NHI-04 — Insecure Authentication | Agent actions depend on how framework-managed identities authenticate to tools and internal systems. | |
| Recommendation — Use NHI-05 to limit agent permissions to task-scoped access and avoid broad service-level grants. Apply NHI-04 to verify how agent identities authenticate before allowing tool or API access. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about production AI systems and the governance needed to control their behaviour. |
| Recommendation — Establish GOVERN processes that assign accountability for agent behaviour, approval boundaries, and oversight. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Agent frameworks need clear permissions and authorizations before they are allowed into production workflows. |
| Recommendation — Apply PR.AA-05 to define and review the permissions granted to agent frameworks and their tool calls. | ||
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.
- Tool calling: Tool calling is the pattern where a model selects and invokes an external function during runtime. In agent systems this turns text generation into action execution, so the access decision must be constrained, logged, and governed like any other privileged interaction.
- Workflow Boundary: The operational limit around which processes, tools, and data an actor may touch. For AI agents, workflow boundaries prevent permission creep by ensuring the system cannot move from one business context to another without explicit governance. This is a control concept, not a user interface concept.
- Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org