How to make an existing web app agent-ready

Making an Existing Web App Agent-Ready

An agent-ready web app is not simply a SaaS product with another chatbot. It lets customer-owned agents, internal automation and the existing interface use the same business capabilities safely.

The architectural goal is a shared application service layer:

UI   REST   GraphQL   MCP
 \     |       |      /
  policy-enforced commands
             |
        domain systems

Commands such as findInvoice, draftCreditNote and submitCreditNote may run in-process or behind an API. Each adapter handles its own discovery, lifecycle and error mapping. MCP provides protocol primitives for tools, resources and prompts. It does not replace sound domain design. Its versioned specification also defines capability negotiation and security boundaries that differ from REST or GraphQL. (modelcontextprotocol.io)

Start with actions, not protocol support

Before adding MCP, confirm that selected workflows provide:

• narrow business operations with validated schemas
• stable identifiers and domain error codes
• object-level and action-level authorization
• defined idempotency for retried writes
• quotas, concurrency limits, timeouts and cancellation
• structured output validated before further use

Avoid broad tools such as executeQuery or updateRecord. Narrow tools reduce ambiguity and limit excessive agency. OWASP identifies prompt injection and overpowered tools as common causes of harmful agent actions. (genai.owasp.org)

Authorization must run inside the application command. Tool discovery or model intent proves nothing. Every execution must recheck the tenant, target object, requested action and delegation ceiling.

Model identity by deployment type

Identity is not always a fixed trio. Record the dimensions that apply:

• Human-delegated agent: user subject, OAuth client, tenant, scopes and delegation chain
• Autonomous workload: workload identity, owning organization, tenant and approved service policy
• First-party UI: user, session, client application and tenant context

A tenant ID supplied in arguments is only a hint. Resolve it from authenticated claims and verified membership.

For HTTP-based MCP authorization, the MCP server acts as an OAuth resource server. It publishes protected-resource metadata and validates tokens intended for its canonical URI. RFC 8707 supports resource and audience targeting but it does not prove tenant membership or create least privilege by itself. Those controls remain application policy. (modelcontextprotocol.io)

Use short-lived tokens, PKCE where applicable and narrow scopes such as credit-note:draft. Never forward the inbound MCP token to a downstream API. Obtain a separate token through an explicit delegation or token-exchange design. The MCP authorization specification requires audience validation and prohibits token passthrough. (modelcontextprotocol.io)

Make approval an application invariant

A model saying "confirmed" is not human approval. For a high-impact command, create a pending operation containing:

{
  "operation": "submitCreditNote",
  "target": "cn_4821",
  "payloadHash": "sha256:...",
  "tenant": "t_17",
  "subject": "u_93",
  "expiresAt": "2026-10-24T18:30:00Z"
}

Show the exact effect through a trusted UI or policy authority. Bind approval to the immutable payload hash, principal, tenant, target and permission. Any material change invalidates it. Consume approval once and reauthorize immediately before execution to reduce time-of-check and time-of-use races.

MCP clients may support user interaction flows but protocol interaction does not replace business workflow state. The server must preserve correlation, expiry and replay status. The official tool guidance recommends visible confirmation for sensitive operations. (modelcontextprotocol.io)

Define retries and errors precisely

For submitCreditNote, scope the idempotency key to the tenant, principal and operation. Store a request hash with the result. Concurrent matching requests should share one execution. Reusing the key with different input should return IDEMPOTENCY_CONFLICT. Define retention and whether failed responses may be replayed.

Keep domain errors stable across adapters:

• VALIDATION_FAILED: safe details, not retryable
• RESOURCE_NOT_FOUND: no cross-tenant existence disclosure
• POLICY_DENIED: not retryable without changed authority
• DEPENDENCY_UNAVAILABLE: retryable with backoff
• APPROVAL_REQUIRED: return a pending-operation reference

REST, GraphQL and MCP can map these differently but the identifier and retry meaning should remain consistent. MCP itself distinguishes protocol errors from tool execution errors. (modelcontextprotocol.io)

Treat all agent content as untrusted

Tool descriptions, resource content and tool results may contain hostile instructions. Treat them as data, not authority. Validate outputs against schemas and encode them for their destination. Restrict outbound hosts to prevent SSRF. Isolate secrets and apply egress controls. Pin trusted server versions and review tool-schema changes.

Add cost-aware quotas, circuit breakers, anomaly detection and an emergency kill switch. Do not assume every "agent" has a cryptographically distinct identity.

Audit effects without leaking data

Record an event ID, timestamp, trace ID, actor chain, tenant, operation, target, policy version, decision, approval reference, idempotency key, outcome and latency. Separate attempted actions from completed effects.

Use field allowlists rather than vague "sanitization." Redact secrets, payment data and unnecessary personal information. Encrypt logs, restrict access, protect integrity and set retention periods.

Legacy applications do not need an immediate rebuild. Wrap one valuable workflow in a policy-enforced command layer. Then connect the UI and one external adapter. Add MCP only after authorization, retries, approval, errors and auditing behave consistently.