US (470) 948-0356 India +91 70321 51545

Cybersecurity

AI agent security

An agent decides what to do and does it, using tools with real permissions. The security of an agent is mostly the security of those permissions, and the boundaries around what the agent reads.

The problem this service solves

Agents read content from the outside world, such as emails, tickets, web pages and documents, and then act. An attacker who can place text in any of those sources can attempt to steer the agent. If the agent can send email, run queries, change records or call internal APIs, the steering has consequences.

The control that matters is not a clever system prompt. It is a design in which the agent holds only the permissions the current task needs, acts as the requesting user and not as a superuser, and requires approval for actions that matter.

What is in scope

  • Identity and delegation

    Whose authority the agent uses, how user identity propagates to tools and whether service accounts are over-privileged.

  • Tool inventory and permissions

    Every tool, its inputs, side effects and the minimum permission each needs.

  • Human approval

    Which actions need confirmation, how the approval is presented and whether it can be manipulated.

  • Untrusted content handling

    How external text enters context and whether it can trigger tool use.

  • Memory and state

    Persistent memory, cross-session leakage and poisoning of stored context.

  • Isolation

    Sandboxing of code execution, network egress control and separation between tenants.

  • Secrets

    How credentials reach tools and whether the model can see them.

  • Audit and kill switch

    Logging of decisions and calls, rate limits and a reliable way to stop an agent.

How the work runs

Model

Draw the trust boundaries.

  1. 1

    Agent architecture review

    Map components, tools, data sources and identities.

  2. 2

    Threat modeling

    Identify abuse paths from untrusted content to sensitive tools.

Test

Try the paths.

  1. 3

    Injection and tool abuse

    Plant instructions in sources the agent reads and see which tools can be driven.

  2. 4

    Permission testing

    Check what a hijacked agent could do as the user and as the service.

Improve

Constrain.

  1. 5

    Control design

    Scoped credentials, approval gates, egress limits, output validation and logging.

What you receive

  • Agent threat model
  • Tool permission matrix with recommended least privilege
  • Test results and transcripts
  • Approval and isolation design
  • Logging requirements
  • Retest results

Tooling and technique

Testing

  • Custom injection harnesses
  • PyRIT
  • garak

Frameworks reviewed

  • LangChain
  • LangGraph
  • OpenAI Agents SDK
  • Anthropic tool use
  • Semantic Kernel
  • AutoGen

Frameworks listed are those our engineers have worked with. Mentioning them does not imply vendor relationships.

Standards we map to

Frameworks and references

  • OWASP Top 10 for LLM Applications (2025)
  • MITRE ATLAS
  • NIST AI RMF

Mapping findings to a framework is not the same as certification against it.

Before we start

What we need from you

  • Architecture and tool list
  • A test environment with realistic but non-production data
  • Policies on which actions require approval

What this service is not

  • Agent development (we can discuss engineering support separately)
  • Evaluating model quality

What changes afterwards

  • Agents hold the least privilege that works
  • High-impact actions need approval the agent cannot give itself
  • Every action is attributable

Questions people ask

Isn’t a good system prompt enough?

No. Prompts are guidance, and a determined input can override them. Enforcement belongs in code outside the model: permissions, approvals and validation.

What is a confused deputy problem for agents?

It occurs when an agent uses its own higher authority to do something a requesting user is not allowed to do. Propagating the user’s identity to tools prevents it.

Related