What breaks is the assumption that connectivity alone is safe enough. A legacy backend may remain unchanged, but a broad schema can make it legible to an agent in ways humans never intended. That creates unintended discovery of sensitive data, privileged relationships, or cross-system actions that were never part of the original workflow.
Why This Matters for Security Teams
Legacy systems usually fail in this scenario because they were designed for bounded users, not autonomous software entities with tool access. Once an agent can read a schema, it can discover tables, relationships, and side effects that were never meant to be machine-legible. That shifts the risk from “can it connect?” to “what can it infer, chain, and invoke?” Guidance from OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both point to the same operational truth: autonomy changes the attack surface more than connectivity does.
NHI security research shows this is not a theoretical concern. In The 52 NHI breaches Report, exposed identity paths and overbroad access repeatedly turn into lateral movement and unintended action, especially when secrets and permissions outlive the task they were meant to support. In practice, many security teams encounter this only after an agent has already discovered a hidden workflow, queried an unexpected object, or triggered an irreversible action rather than through intentional testing.
How It Works in Practice
The failure mode is usually a combination of broad schema exposure, static credentials, and weak runtime authorisation. A legacy backend may still enforce its own checks, but if the agent can enumerate fields, relationships, and callable endpoints, it can reason across systems in ways the original designers never anticipated. That is why current guidance from NIST AI Risk Management Framework emphasizes governance, context, and ongoing monitoring rather than one-time access grants.
Practically, teams need to reduce what the agent can see and what it can do at the moment of use:
- Expose only task-specific schema views, not the full backend model.
- Issue JIT credentials with short TTLs instead of long-lived secrets.
- Bind access to workload identity so the system knows what the agent is, not just what token it holds.
- Use intent-based or context-aware authorisation so approval happens at request time, based on the action being attempted.
- Log and review agent queries, joins, retries, and tool calls as security events, not just application telemetry.
Where possible, this should sit inside a ZTA model with policy-as-code checks at each decision point. That can be implemented with OIDC-backed workload identity, SPIFFE/SPIRE-style identity attestation, and runtime policy engines that evaluate the exact task, target system, and privilege boundary before execution. The operational goal is to make the agent prove necessity for every action, rather than assuming the schema can safely describe the environment. These controls tend to break down when the legacy system has no meaningful API boundary and the only available interface is a broad, queryable data plane.
Common Variations and Edge Cases
Tighter schema governance often increases integration overhead, requiring organisations to balance developer speed against containment. That tradeoff is real, especially in environments where older platforms, ETL jobs, and ad hoc reporting all depend on the same dataset. There is no universal standard for this yet, but best practice is evolving toward least-disclosure schemas, per-workflow access, and temporary secrets rather than blanket exposure. The OWASP NHI Top 10 and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that identity lifecycle and access scope matter as much as code-level validation.
Edge cases appear when agents are allowed to compose multiple tools, call downstream APIs, or use delegated credentials across service boundaries. In those environments, a harmless read can become a privileged write if the schema reveals join paths, foreign keys, or undocumented administrative functions. The same risk shows up when a long-lived service account is reused across many tasks, because revocation becomes nearly impossible once the agent has cached context. For governance teams, the practical test is simple: if an agent can infer a relationship that a human operator would not discover without privileged context, the schema is too broad. That limitation becomes most severe in multi-tenant systems, where a single leaked structural clue can expose multiple customers or internal trust relationships.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Autonomous agents need bounded tool use and runtime checks, not broad schema exposure. |
| CSA MAESTRO | T1 | MAESTRO addresses threat modelling for agentic workflows and hidden side effects. |
| NIST AI RMF | GOVERN | AI RMF governance fits intent-based authorisation and accountability for agents. |
Assign ownership, monitor behaviour, and enforce context-aware decisions for each agent task.
