AI agents expand the attack surface: APIs, permissions, and a secure POC

A chatbot receives text and returns text. An AI agent can receive a request, retrieve documents, call APIs, decide which tool to use, and change a system on someone's behalf. That difference changes the threat model. The risk no longer ends with an incorrect response: it reaches every piece of data, credential, and operation available during execution.

When chat becomes a control plane

A typical architecture connects the model to an orchestrator, memory, a search mechanism, internal APIs, and third party services. Each connection adds a trust boundary. An instruction may come from the user, but also from an email, a retrieved document, an API response, or another agent's message. If the model can turn that content into a tool call, any untrusted input can try to influence a privileged action.

Excessive permissions turn an error into impact

OWASP describes excessive agency through three root causes: excessive functionality, permissions, and autonomy. An agent built to summarize tickets does not need to edit users, run arbitrary queries, or send messages. Yet the integration often reuses a broad service account because it is faster for the POC. In that design, the model does not break authorization. It simply uses a credential that was already granted too much authority.

• Expose only the tools required for the use case, with no generic shell or HTTP client when a specific function will do
• Separate read, create, update, and delete into distinct operations with their own scopes
• Execute each action in the user's context or through an identity dedicated to the function, never through a shared administrative account
• Require independent approval for destructive, financial, administrative, or externally visible actions
• Apply limits for calls, time, cost, chain depth, and volume per session

A secret in context is still an exposed secret

API keys, OAuth tokens, and database credentials should not appear in the prompt, memory, tool output, or raw agent logs. The model needs the result of an authorized operation, not the secret that authorizes it. A tool gateway can retrieve the credential from a vault, call the service, and return only permitted fields. Short-lived tokens, minimal scopes, and rotation reduce the time and reach of a leak.

The same rule applies to business data. Before building context, the application must enforce user and object authorization, classification, minimization, and masking. Retrieving a document by similarity does not prove the requester may read it. If authorization filtering happens after retrieval, another department's or tenant's data may already have entered the context and may reappear in the response or an external call.

Inputs and outputs need separate contracts

Every external input must be treated as untrusted data, including responses from APIs considered partners. Validating size, type, format, and origin reduces ambiguity, but it does not solve prompt injection by itself. The important decision is architectural: retrieved content must not expand permissions, enable a tool, or remove an approval required by policy.

Model output is also another component's input. SQL, HTML, file paths, email recipients, and tool arguments must pass schema validation, allowlists, encoding, and authorization before use. OWASP calls this problem Improper Output Handling. Trusting a response's fluency as if it were validation allows manipulated output to reach an interpreter or privileged API.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "tool": { "const": "crm.read_contact" },
    "contact_id": {
      "type": "string",
      "pattern": "^[a-z0-9-]{1,64}$"
    }
  },
  "required": ["tool", "contact_id"],
  "additionalProperties": false
}

A third party integration is part of the attack chain

Plugins, connectors, MCP servers, models, vector databases, and SaaS APIs are part of the agent's supply chain. NIST AI 600-1 recommends inventorying third parties with access to organizational content, assessing supplier risks, maintaining monitoring, and preparing incident response. In practice, asking whether the supplier encrypts data is not enough. You need to know which data it receives, where it is stored, how long it is retained, who can invoke the integration, and what happens when it fails or is compromised.

• Maintain an inventory of models, tools, APIs, data sources, and the owner of each integration
• Pin versions and verify connector origin, signatures, and changes when the ecosystem provides those controls
• Define timeouts, limited retries, a circuit breaker, and safe behavior for missing or malformed responses
• Remove experimental tools that are no longer required and revoke their credentials
• Plan how to disable the connector and preserve evidence without depending on the affected supplier itself

Without traceability, there is no reliable investigation

Recording the conversation alone is not enough. An investigation must reconstruct which agent version was active, who started the session, which identity was used, which sources entered the context, which tool was requested, which parameters were normalized, which policy decided, who approved, and what the result was. Logs should preserve correlation and integrity without storing unnecessary tokens or sensitive data.

• Session, user, agent, model, system prompt, and policy version identifiers
• Source and classification of retrieved data, with sensitive content masked
• Tool, target, normalized parameters, authorization decision, and approval identifier
• Result, error, latency, retry count, and activation of limits or a circuit breaker
• Alerts for unusual tools, repeated denials, privilege elevation, and volume outside the expected pattern

Practical criteria for a secure POC

A POC exists to reduce uncertainty, not to silently inherit production controls. It can operate with synthetic data, an isolated environment, and a narrow scope. Before connecting real data or onboarding users, define verifiable entry and exit criteria. OWASP itself recommends structured testing before production and after material changes to prompts, tools, memory, retrieval, policies, or the model provider.

• The use case, users, data, tools, and permitted actions are documented
• Synthetic or minimized data replaces sensitive information whenever possible
• Every credential is dedicated, short-lived, revocable, and restricted to the required resource
• Structured outputs fail closed when they do not pass schema validation or authorization
• High-impact actions require approval bound to the exact target and parameters
• Direct and indirect prompt injection, tool abuse, privilege escalation, exfiltration, and memory poisoning have repeatable test cases
• Limits stop loops, retries, consumption, and tool chains outside the expected behavior
• Logs can reconstruct the decision without exposing secrets
• A named owner can stop the POC, revoke access, and handle incidents

Pentesting starts at the boundaries, not the prompt

Testing only whether the model refuses a jailbreak leaves most of the surface untested. An agent pentest must cross the application, APIs, authorization mechanism, memory, tools, and third party services. We test whether controlled input can change a decision and, more importantly, whether controls outside the model prevent that decision from becoming unauthorized access, modification, or data transfer.

For a company deciding whether a POC can advance, the useful question is not whether the agent appears intelligent. It is whether the system remains secure when the model is wrong, manipulated, or given a malformed response. That is where an architecture review and abuse-oriented pentest produce evidence for the production decision. Technical references consulted: OWASP Top 10 for LLM Applications 2025, OWASP AI Agent Security Cheat Sheet, and NIST AI 600-1.