A hand-built agent solves one narrow job with one owner and one set of credentials. An internal agent platform provides the substrate for many agents: shared connections, scoped access, isolated memory, audit logs, and reusable skills. The distinction matters because the platform is designed for accountability and scale, while the bespoke agent is designed to prove a single workflow first.
Why This Matters for Security Teams
The difference is not just architectural, it is operational. A hand-built internal agent can be reviewed like a single application with a clear owner, narrow scope, and limited blast radius. An internal agent platform, by contrast, creates a shared control plane for many agents, which means access boundaries, memory handling, tool permissions, and auditability must be designed once and enforced consistently. That shift changes how risk is measured, because the platform becomes part of the security boundary rather than just an implementation detail.
This is where issues like prompt injection, overbroad tool access, and credential sprawl become harder to dismiss as one-off bugs. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward the same practical issue: accountability has to survive reuse, delegation, and scale. In practice, many security teams encounter agent platform risk only after a second or third agent inherits permissions that were safe for the first workflow but unsafe for the broader estate.
How It Works in Practice
A hand-built agent usually bundles its own prompt logic, tool calls, and access tokens around one task. That makes it easier to reason about, but harder to reuse. An internal agent platform separates concerns: one layer handles identity, one layer brokers tool access, one layer manages memory or state, and another layer records audit events. This creates consistency, but it also introduces a governance problem because the platform can amplify mistakes across every agent that uses it.
In practice, the platform should be treated like an internal service boundary with explicit policy enforcement. The main design choices are:
- Scoped credentials so each agent receives only the access it needs for a bounded job.
- Tool allowlists so actions are approved centrally rather than embedded in each agent.
- Isolated memory so one workflow cannot contaminate another with stale or sensitive context.
- Audit logs that capture prompts, tool calls, approvals, and exceptions in a format the security team can review.
- Reusable skills or templates that standardise behaviour without copying privileged logic into every implementation.
Security teams should also consider whether the platform supports testing for prompt injection, privilege escalation, and unsafe delegation before agents go live. The MITRE ATLAS adversarial AI threat matrix is useful here because it frames the attack surface around how agents are manipulated, not just how models are trained. These controls tend to break down in loosely governed developer sandboxes where agents can register tools dynamically and inherit shared secrets from a common runtime.
Common Variations and Edge Cases
Tighter platform governance often increases build and review overhead, requiring organisations to balance speed for a single workflow against the long-term benefits of standardisation. That tradeoff matters because not every internal agent deserves to start on a platform. For a one-off automation with low privilege and minimal data exposure, a hand-built agent can be the correct choice, especially when the goal is to validate usefulness before investing in shared infrastructure.
Best practice is evolving on where the platform line should sit. Some teams centralise only identity, secrets, and logging, while leaving business logic in the agent itself. Others go further and enforce shared policy, memory controls, and model routing through the platform. There is no universal standard for this yet, but the rule of thumb is simple: the more an agent can reach, remember, or delegate, the more it belongs inside a governed platform model rather than a bespoke script.
Edge cases appear when agents handle regulated data, high-value transactions, or cross-system actions. In those environments, a platform should support separation of duties, replayable audit trails, and rollback paths for unsafe actions. Where multiple teams build agents independently, the hidden risk is not only inconsistent quality, but inconsistent identity and privilege handling across the estate.
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, MITRE ATLAS and CSA MAESTRO 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 |
|---|---|---|
| NIST AI RMF | Agent platforms need governed AI lifecycle risk management and accountability. | |
| OWASP Agentic AI Top 10 | Agentic systems face prompt injection, tool misuse, and delegation abuse. | |
| MITRE ATLAS | Adversarial AI threats explain how agents can be manipulated through prompts or context. | |
| CSA MAESTRO | Agent platforms need threat modeling for orchestration, delegation, and runtime boundaries. | |
| NIST CSF 2.0 | PR.AC-4 | Scoped access and identity controls are central to platform versus bespoke agent design. |
Apply GOVERN and MAP practices to define ownership, roles, and risk controls for agent reuse.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between agent identity and agent authorization in AI governance?
- What is the difference between proxying an AI agent's API call and minting a short-lived token for the agent?
