Assets and actors
Map sensitive data, credentials, actions, systems, logs, models, prompts, code, users, administrators, suppliers, attackers, and trusted boundaries.
Enterprise AI security
How should an enterprise security-review an AI agent?
Review the complete system, not only the model. Trace untrusted content through retrieval and tool calls, enforce identity and least privilege outside prompts, isolate tenants and secrets, constrain data egress and dependencies, verify every consequential action, and rehearse detection, revocation, recovery, and evidence preservation.
By Onyx Devs Lab · Published · Updated
ThreatsUsers, content, models, tools, suppliers, and insiders
BoundariesIdentity, tenants, data, secrets, tools, and networks
ResponseDetect, contain, revoke, recover, and learn
Threat-model the end-to-end agent
Agent risk arises from interactions among content, memory, tools, identities, vendors, and business systems.
Attack paths
Test prompt and indirect injection, confused deputy, cross-tenant access, data poisoning, secret exposure, tool abuse, unsafe files and URLs, dependency compromise, denial of service, and insider misuse.
Failure consequences
Classify confidentiality, integrity, availability, financial, legal, safety, customer, and operational impact; identify mandatory controls and actions that remain prohibited.
Enforce controls outside model judgement
Natural-language policy is not an access-control, transaction, or recovery system.
Identity and least privilege
Authenticate users and services, authorise at the target, use scoped short-lived credentials, separate environments and tenants, limit networks, and protect secret creation, storage, use, and rotation.
Safe tools and data flow
Validate typed inputs and outputs, bind confirmation to exact actions, apply allowlists, limits, sandboxing and egress controls, scan content, and verify resulting state.
Detection and recovery
Record actor, context, policy, tool, target, request, result, and model/configuration versions; alert on abuse, support kill switches, revoke access, reconcile state, restore service, and preserve evidence.
How to approve bounded agent authority
Define scope and threat model
Document architecture, assets, actors, trust boundaries, data flows, tools, suppliers, failure impact, assumptions, and excluded actions.
Test controls adversarially
Use authorised scenarios for injection, permission bypass, tenant crossing, exfiltration, tool misuse, replay, race, partial failure, dependency loss, and logging gaps.
Close mandatory findings
Assign owner, severity, exploit conditions, affected assets, remediation, compensating control, retest evidence, exception authority, and expiry.
Approve bounded authority
Release only the tested users, data, tools, limits, environments, and monitoring; rehearse containment, revocation, recovery, and notification.
Frequently asked questions
Is a model provider security report sufficient?
No. It informs supplier risk but does not cover your identities, data, retrieval, tools, integrations, configuration, users, monitoring, or incident response.
Can prompt instructions enforce security policy?
No. Prompts can guide behaviour but enforceable policy must live in identity, authorisation, network, data, tool, transaction, and monitoring controls.
What is the safest first authority level?
Read-only access to a narrow authorised source with citations, no secrets in context, monitored usage, clear abstention, and qualified human review.
Start with one concrete operating problem.
We will first clarify the workflow, evidence, data boundary, and outcome standard before recommending the next step.
Contact Onyx