AI & agent security.

An AI assistant can retrieve internal documents. A coding agent can read repositories and run commands. A business agent can call APIs, update records, and send information outside your organization. Each needs limits on the data it can access and the actions it can take.

Broadwing tests how AI systems can be manipulated and engineers controls over sensitive data, identities, tools, and actions. We work with teams adopting AI tools and building AI applications, combining adversarial testing with application, infrastructure, and data engineering.

Broadwing has built custom Model Context Protocol (MCP) integrations for customers, worked with major coding agents, and used and customized coding-agent SDKs.

We have used major model providers and are familiar with vLLM for inference serving, open-weight and open-source models, and System One models such as TypeSafe's Jev for structured decision-making.

That experience informs the review: what an integration exposes, which credentials an agent uses, and how a generated instruction becomes a tool call or a code change. We test those paths and implement controls in the application and connected services.

Employee AI tools

Help teams use AI while controlling how company information enters prompts, attachments, connected applications, and conversation histories.

We review which data employees may share, provider retention and training settings, connected-data permissions, and available logging. We help configure sharing and access restrictions, and document handling rules where the tool cannot enforce them.

AI applications and agents

Review the systems you build or operate: retrieval-augmented generation (RAG) applications that answer from connected data, assistants, tool-using agents, and automated workflows.

We trace the initiating user's identity through retrieval and tool execution, examine service-account privileges, and test how untrusted content affects behavior. We help enforce record-level access, restrict tool actions, validate outputs before downstream use, and limit command execution and outbound connections.

AI-assisted development

Examine what coding assistants and development agents can read, change, execute, and deploy.

That includes repository permissions, access to secrets, shell and network permissions, execution environments, dependency changes, and the review path for generated code. Repository files, issue text, and tool responses can also contain instructions that influence an agent; those inputs belong in the threat model.

Prompt-injection testing and defense

Test attempts to redirect the model through user prompts or instructions embedded in retrieved documents, web content, email, or tool responses. Check whether the application follows those instructions and whether the resulting output can disclose sensitive data or trigger unauthorized actions.

Defenses can include separating trusted instructions from external content, validating inputs and outputs, and restricting resources and actions. Application code and downstream services must enforce authorization and execution limits even when the model follows a malicious instruction.

Authorization at retrieval and tool boundaries

A shared service account can give an assistant access to more information than the person using it. We examine how user permissions carry through to source systems, retrieval indexes, and downstream APIs.

We help enforce permissions before content enters the model's context and before a tool acts. For example, a request for another user's restricted record should be rejected by the retrieval service, rather than left to the model to withhold from its answer.

Agent identities, tools, and execution

Apply least privilege to agent identities and the tools they use. Review token scopes, available functions, destinations, execution environments, and access to secrets.

For tool integrations, including MCP servers, review authentication, token scopes, tool arguments, and the trust placed in tool descriptions and responses. A read-only connector should reject updates or deletions at the service boundary. Enforce approvals for high-impact actions where required by the workflow, and limit execution and outbound access to the task's needs.

Structured decisions and automated actions

Jev and related structured-decision models return choices or scores that software uses to classify, route, or act. We review the allowed outputs, confidence thresholds, fallback behavior, and permissions on the actions those decisions trigger. Tests check whether misleading inputs can cause incorrect decisions or unauthorized actions, even when the output matches its schema.

Sensitive-data handling

Map where information passes through prompts, retrieved context, tool calls, provider services, outputs, and logs. Address disclosure paths, retention, and the permissions needed to view those records.

Prompt and tool traces can contain customer information, source code, or credentials. Limit what is logged, who can read it, and how long it is retained.

For self-hosted inference, including vLLM deployments, the review also covers endpoint authentication, network exposure, model-loading code, and the origin of model artifacts. Keeping inference on your infrastructure still requires controls over who can call the service and what it can access.

Observability and repeatable evaluation

Connect activity to the initiating identity, data sources, tool calls, authorization decisions, and relevant model or configuration versions. Establish what should trigger review or escalation and who acts on it.

Build evaluation cases that pair authorized tasks and adversarial inputs with expected behavior: which records may be returned, which tool actions must be denied, and what should be logged. Re-run relevant checks when the model, prompts, tools, permissions, or retrieval sources change.

This example describes a security design and validation approach. It is not a client case study or a measured Broadwing result.

The workflow: An internal assistant searches company documents and can send a summary by email.

The exposure: A retrieved document contains instructions intended to make the assistant access unrelated sensitive records and send them to an external address. A broadly privileged retrieval identity and unrestricted email tool would increase the potential impact.

The controls: Enforce the user's access before retrieved content reaches the model. Restrict the email tool's actions and recipients, limit other outbound paths, and log retrieval and sending decisions. If policy permits external sharing of sensitive material with approval, enforce that approval in the sending workflow.

The validation: Pair each test with an expected result:

For an actual evaluation, record the observed result, evidence, and model, prompt, and tool versions alongside each case.

These checks test the data and action boundaries in this workflow; they do not establish that every prompt-injection attempt will be prevented.

An engagement can include:

• A threat model and a map of identities, data flows, tool access, and trust boundaries.
• Adversarial findings with reproducible scenarios and prioritized remediation.
• Implemented controls around retrieval, tool use, sensitive data, and execution.
• An evaluation suite with authorized and adversarial test cases, expected behavior, and recorded results.
• Logging configuration, escalation guidance, and instructions for rerunning evaluations within the agreed scope.

We can assess an existing system, work alongside the team building it, or help maintain the controls and evaluations through ongoing support.

Can prompt injection be solved with better system prompts?

System prompts help define intended behavior, but they do not establish an authorization boundary. We combine behavior-level defenses with controls over retrieval, tools, credentials, and execution. Testing should establish what the system can expose or do when those behavioral defenses are challenged.

Do you cover coding agents as well as customer-facing AI?

Yes. Development agents create their own access and execution paths through repositories, tools, dependencies, and credentials. We review those permissions and workflows alongside the process for validating and merging their changes.

Can you secure AI that is already in production?

We can start by mapping its data access and actions, testing the relevant attack paths, and prioritizing changes with your team. The scope accounts for the application, provider capabilities, and production constraints.

What standards inform the assessment?

OWASP's guidance for generative AI provides useful coverage for risks such as prompt injection, sensitive-information disclosure, and excessive agency. We use those categories to inform testing, then tie the findings to the identities, data, tools, and business operations in your system.

Tell us what the AI connects to, what it can do, and which data or actions matter most. We will review the fit and scope the testing and engineering work with you.

Discuss an AI-security review →

Select Security on the contact form and mention AI security. Tell us whether the work concerns employee tools, an AI application or agent, or an AI-assisted development workflow.

Related: Data security & governance · Security testing & remediation · Security engineering