There are two common starting points:

 

Both need dependable interfaces and application controls. An agent being developed by your own team does not make every action it proposes trustworthy.

Before reviewing the AI agent architecture, write a scope statement: the user, task, tenant or account boundary, data sources, permitted actions, approval requirements, expected outcome, and release configuration.

For example: “An authenticated support specialist can ask the agent to draft a reply using records they may access and create one internal follow-up task. Sending the reply, issuing refunds, and changing account permissions are excluded.”

This is much more useful than declaring the whole product “AI ready SaaS.” A product might support that narrow workflow while remaining unprepared for autonomous refunds.

Review each check against the scope statement. Assign one of four statuses:

 

For each result, record the evidence, reviewer, responsible owner, review date, and repair acceptance criteria where needed. A document describing an intended control is weaker evidence than a test showing that the deployed boundary enforces it.

Do not convert these statuses into a percentage-based readiness certificate. Twenty-four verified checks do not cancel out one broken authorization boundary.

Scope and authority: checks 1 to 5

1. The workflow has a verifiable outcome

Inspect: The supported user task, business acceptance criteria, excluded tasks, and refusal or escalation behavior.

Pass condition: The team can distinguish a completed task, a correct refusal, an escalation, and an unsuccessful attempt using evidence beyond the agent’s own success message.

For a follow-up task, success might require a persisted task linked to the correct ticket and tenant. A persuasive response saying “done” is insufficient. Define when the agent should ask for missing information rather than invent it. Product and engineering should agree on this contract before evaluating model performance.

2. The capability inventory matches the intended authority

Inspect: Every available tool, credential, integration, and indirect route to reading or changing data.

Pass condition: The enabled capabilities are limited to the reviewed workflow. Reads, writes, external communications, and administrative actions have explicit boundaries.

A reply-drafting agent should not inherit a general administrator tool because that tool is convenient for development. Include secondary effects such as notifications triggered by an update. OWASP’s excessive-agency guidance identifies excessive functionality, permissions, and autonomy as separate sources of risk. Review all three, including capabilities available through connected services.

3. Identity and tenant context come from trusted application controls

Inspect: Caller authentication, workload credentials, tenant selection, delegated access, and credential expiry or revocation handling.

Pass condition: The executor knows whose authority is being used and which account context applies. A model-generated tenant identifier cannot override the trusted context.

A signed-in user’s delegated operation and a background service operation may require different identity patterns. Microsoft’s identity guidance distinguishes delegated and application access. Select the pattern deliberately, keep credentials out of model-visible context, and test invalid or expired credentials. If a workflow is intentionally public, document its limited anonymous authority.

4. Authorization is enforced for objects, properties, and functions

Inspect: Server-side permission checks on records, writable fields, sensitive outputs, administrative functions, and tenant boundaries.

Pass condition: Requests outside the caller’s authority are denied even when the agent supplies a valid-looking identifier or payload. Changing an identifier cannot reveal another tenant’s record or modify a forbidden field.

Authentication identifies a caller; it does not establish permission for every record. OWASP separates object-level authorization from property-level authorization. Test both. Hiding a tool in the interface does not replace authorization at the endpoint that performs the operation.

5. Required approvals apply to the exact action executed

Inspect: Approval requirements, the information shown to the approver, the proposed payload, expiry rules, and execution-time validation.

Pass condition: Where approval is required, execution uses the approved action and relevant current conditions. A changed recipient, amount, scope, or other material input triggers the required review again.

Define which actions need approval based on their consequences. Capture enough detail for an informed decision rather than offering a generic “allow agent” button. Recheck authorization and business preconditions when executing. A prior approval should not silently authorize a different action or preserve access that has since been revoked.

AI agent API architecture: checks 6 to 10

6. Tools expose clear, bounded business operations

Inspect: Tool names, descriptions, discovery, documented side effects, and overlap between operations.

Pass condition: Tools make their purpose and limits clear, and their implementation enforces those limits. Generic database, shell, or unrestricted outbound-request access is avoided unless specifically justified and controlled.

An HTTP API can use OpenAPI to describe its contract. MCP can expose callable tools, but the MCP tool specification cautions that annotations are untrusted unless they come from trusted servers. A “read-only” description is not proof of behavior. Exercise the operation and inspect its actual effects.

7. Schemas are backed by deterministic business validation

Inspect: Input and output schemas, required fields, permitted values, units, size limits, and domain rules.

Pass condition: Malformed or prohibited requests are rejected before effects occur. Valid syntax cannot bypass business constraints.

A numeric field does not establish that a requested adjustment is allowed. An identifier string does not establish that the record belongs to the account. Test missing fields, unexpected properties, excessive payloads, incorrect units, and domain-invalid combinations. Keep validation at the service boundary so it also protects against mistakes made by external agents and ordinary API clients.

8. Responses distinguish acceptance, completion, and uncertainty

Inspect: Error contracts, asynchronous job responses, result lookup, and the agent’s interpretation of each state.

Pass condition: The caller can distinguish rejected, accepted, running, completed, and failed work, with an explicit path for an uncertain result.

HTTP semantics define 202 Accepted as acceptance for processing rather than completed processing. Your agent must preserve that distinction. Provide durable identifiers and a supported status mechanism where work is asynchronous. Test that an accepted request or lost response does not produce an unsupported “completed successfully” claim to the user.

9. Repeated requests do not create duplicate business effects

Inspect: Operation identity, deduplication behavior, storage and retention, payload matching, and third-party idempotency contracts.

Pass condition: Repeated delivery of the same intended operation is handled safely within documented limits. Changed intent is distinguishable from a retry.

AWS’s idempotent-API guidance explains the value of caller-provided request identity and the complications of different parameters or late requests. Keep identity stable across a retry; a fresh key on every attempt defeats that purpose. Test response loss after an effect occurs. Document what happens after the deduplication window expires rather than assuming protection lasts forever.

10. Concurrent changes cannot be silently overwritten

Inspect: Preconditions, record versions, transaction boundaries, and conflicts between agent, user, and background updates.

Pass condition: A stale proposal is rejected, reconciled, or deliberately revalidated under the product’s rules before it changes current state.

HTTP conditional requests, including If-Match where supported, are one way to prevent lost updates. Your application may use another concurrency mechanism. Test the actual implementation: let a user change a record after the agent reads it, then attempt the agent’s update. Confirm that the newer legitimate change is preserved or handled through an explicit conflict policy.

Data, context, and state: checks 11 to 15

11. The agent knows which sources are authoritative

Inspect: Source ownership, business definitions, timestamps, provenance, and conflicts between live records and retrieved documents.

Pass condition: The workflow uses an identified source of truth for consequential facts and handles unavailable or conflicting evidence according to a defined rule.

A knowledge article may explain how a subscription works while the account database determines the customer’s current entitlement. Retrieval relevance does not make those sources interchangeable. Test missing records and contradictory information. Require useful source references for claims where users need to inspect the evidence, without presenting a citation as proof that the underlying content is correct.

12. Permissions follow data through retrieval and delivery

Inspect: Search filters, document permissions, caches, generated outputs, downloadable artifacts, source links, and data sent to model providers.

Pass condition: A user receives only information permitted for the workflow, with approved handling of sensitive data across the full path.

This check complements endpoint authorization: a protected database can still feed an improperly scoped retrieval index. Microsoft’s secure multitenant RAG guidance applies tenant and user access controls to retrieval. Test cache reuse and links as well as retrieved text. Verify applicable provider-processing, retention, and location requirements against actual configuration and agreements.

13. Updates, deletions, and access revocations reach derived data

Inspect: Synchronization, deletion handling, access changes, stale caches, and the delay between source changes and retrieval.

Pass condition: The workflow meets defined freshness requirements and prevents unauthorized retrieval after access changes. Deleted material is handled according to the product’s retention rules.

Do not assume indexing automatically handles every change. For example, Azure AI Search’s indexer documentation explains that orphaned documents are not automatically deleted without suitable deletion handling. Test your chosen system directly: remove access, update content, and delete a source record. Verify the resulting retrieval behavior, including cached paths.

14. Memory has an explicit scope and trust boundary

Inspect: Persistent conversation history, learned preferences, shared memory, write permissions, retention, and clearing behavior.

Pass condition: Memory belongs to the correct user, tenant, and purpose. Untrusted content cannot become trusted policy merely because it was saved for later.

OWASP’s memory-security discussion describes persistent memory as an attack surface. Test cross-user reuse, poisoned entries, and access changes. Define what can be remembered and who can inspect or remove it. If the workflow has no persistent memory, record that fact rather than adding a memory subsystem to satisfy the audit.

15. Execution state can be resumed without inventing progress

Inspect: Saved workflow state, approved payloads, action identifiers, pending results, checkpoint behavior, and crash recovery.

Pass condition: Resumption identifies completed, pending, and uncertain operations and avoids treating internal state as proof of external effects.

Framework behavior matters. LangGraph’s time-travel documentation explains that later nodes can re-execute model and API calls during replay. A checkpoint therefore does not automatically undo an external action. Test a crash before dispatch, after dispatch, and after a remote effect but before its result is recorded. Keep the resumed workflow consistent with verified business state.

Safety and reliability: checks 16 to 20

16. Untrusted content cannot grant new authority

Inspect: User messages, retrieved documents, tool results, tool metadata, and instructions embedded in external content.

Pass condition: Malicious instructions cannot bypass enforced permissions, expand available capabilities, or redirect sensitive data to an unauthorized destination.

OWASP’s prompt-injection guidance explains why retrieval or model tuning does not eliminate this problem. Treat relevant content as data rather than a source of authority. Restrict outbound tools and destinations where appropriate. Test malicious content in realistic retrieval and integration paths. Measure behavioral resistance, while keeping critical security boundaries enforced independently of model compliance.

17. Model output is handled safely by downstream software

Inspect: Generated content passed into HTML, SQL, commands, templates, files, or other interpreters.

Pass condition: Outputs receive the validation, escaping, parameterization, or sandboxing appropriate to their destination. Model text is not automatically trusted executable input.

This differs from checking API arguments. A correctly shaped reply can still contain unsafe markup. OWASP’s improper-output-handling guidance covers risks created when downstream systems mishandle generated output. Test the rendering and execution boundaries actually used by the product. Keep secrets and unnecessary sensitive data out of prompts and generated artifacts.

18. Resource consumption has enforceable limits

Inspect: Model and tool budgets, iteration limits, latency, request sizes, concurrency, tenant quotas, and alert thresholds.

Pass condition: The workflow stops or degrades predictably when it reaches its limits, without allowing one tenant or looping task to exhaust shared capacity.

AWS’s agentic-AI performance guidance recommends tenant-aware resource controls and monitoring. Set limits from the product’s expected workload and cost tolerance, then test them. Include downstream tool consumption, not only model tokens. Record verified task completion alongside cost and latency so a cheap failed workflow is not mistaken for an improvement.

19. Failures have bounded retries and honest user states

Inspect: Retry ownership, retryable errors, backoff, timeouts, cancellation, provider outages, and fallback behavior.

Pass condition: Retries are bounded and appropriate to the operation. The user sees a truthful pending, failed, or escalated state when completion is unverified.

AWS’s reliability guidance warns about uncontrolled retries and repeated side effects. Check whether multiple layers multiply attempts. Permission failures should not trigger endless retries. Test that local timeout or cancellation is not treated as proof that remote work stopped. A fallback should preserve permissions and business rules, including when a human takes over.

20. Every consequential action has a recovery decision

Inspect: Actions that change records, send messages, grant access, or trigger external work; their recovery mechanisms and responsible owners.

Pass condition: The team can identify an effect, reconcile uncertain results, and follow a tested correction, compensation, cancellation, or containment path appropriate to that action.

Microsoft’s compensating-transaction pattern describes application-specific recovery that must account for concurrent changes and can itself fail. Define limits honestly: a delivered message cannot simply be made unseen. A recovery plan should protect later legitimate work and specify when manual intervention is required.

Evaluation, releases, and operations: checks 21 to 25

21. Evaluation measures real outcomes across representative cases

Inspect: Test cases, expected outcomes, grading criteria, repeated trials, and examples held back from prompt tuning.

Pass condition: The release meets documented quality criteria for the reviewed task, including correct refusal and escalation, with limitations recorded.

Anthropic’s agent-evaluation guidance distinguishes a run’s transcript from its resulting environment state and discusses repeated trials. Include ordinary tasks, ambiguity, missing data, and meaningful edge cases. Verify persisted effects directly when possible. Calibrate subjective grading with qualified human review. A demonstration on a few handpicked prompts is weak evidence of broader reliability.

22. Security and failure tests exercise the real boundaries

Inspect: Negative access tests, integration failures, duplicate delivery, revoked authority, hostile content, and concurrent changes.

Pass condition: Relevant prohibited operations are denied and relevant failures reach the designed safe state in an authorized test environment.

Use isolated accounts and representative tenant fixtures. OWASP’s API authorization testing guidance includes checking access across accounts. Test real service enforcement, rather than only asking whether the model will choose the right tool. Exercise the model path too, but do not let a well-behaved model conceal a permissive endpoint.

23. Releases identify configuration and state compatibility

Inspect: Code, prompts, model identifiers and settings, tools, retrieval configuration, policies, and saved-state schemas.

Pass condition: The team can identify the relevant configuration for a run and explain how new, queued, paused, and running work behaves after a change.

Temporal’s workflow-versioning documentation illustrates the compatibility requirements of replay-based workflows. Your platform’s exact rules may differ. Test migrations or supported resumption paths. Where model providers do not expose immutable versions, record that limitation and monitor changes. Reverting application code alone does not establish compatibility with current state or earlier external effects.

24. Observability connects requests to verified effects

Inspect: Correlation identifiers, tool calls, execution decisions, approvals, provider results, release references, outcome metrics, and protected telemetry access.

Pass condition: An authorized operator can reconstruct a consequential action and investigate failures without relying on an unverified narrative from the agent.

Google Cloud’s agent-observability guidance covers execution and tool behavior alongside operational signals. Capture relevant events and evidence while minimizing sensitive content. Define redaction, retention, and log access. Do not require disclosure of a model’s hidden chain of thought. Trace the observable decisions and effects that support debugging and accountability.

25. Ownership, containment, and human handoff are operational

Inspect: Incident ownership, support escalation, customer-facing failure states, and controls for new, queued, and in-flight actions.

Pass condition: A responsible operator can restrict the affected capability, identify work already underway, and coordinate verified recovery and user support.

Test containment against the actual action executor. Disabling a chat button might leave a background queue running. Define what can still complete after shutdown and how its result is reconciled. Make handoff useful by preserving authorized context and pending status. The team should know who maintains tools, reviews incidents, and approves resumption after repairs.

An agent-ready architecture is supported by evidence at its boundaries. Audit findings should produce a specific release decision, not a badge for the whole company.

Record the reviewed workflow, configuration, permitted users, authority, operating limits, and unresolved issues. Define blockers according to consequences. Unauthorized disclosure, prohibited actions, and unsafe repetition of consequential operations should block the affected capability. Unknown results on those boundaries are unresolved, not presumed safe.

For less consequential gaps, document whether a reduced scope, added review, or restricted rollout is justified by tested controls. Manual review cannot compensate for information that is already disclosed before that review occurs.

Use a finding record such as:

 

Keep ordinary security, privacy, accessibility, and reliability reviews alongside this audit. The 25 checks address agent-specific readiness; they do not replace all requirements for operating a SaaS product.

Consider a hypothetical multitenant support product. The proposed agent drafts replies and creates internal follow-up tasks. It cannot send messages, issue refunds, or administer accounts.

The demo works. A review then produces these findings:

 

These findings do not establish a release decision for the entire product. They show that the proposed scope is not yet supported by the required evidence.

Removing task creation narrows the write risk, but drafting still requires verified access controls and retrieval behavior. A reduced scope needs its own review.

This is the practical value of an agent-ready SaaS audit: it reveals which capability needs repair and how to prove the repair worked. It also gives founders a concrete way to evaluate a delivery proposal without having to choose the agent framework themselves.

The useful output of this audit is a defined workflow, a set of verified controls, and an owned repair plan for the remaining gaps.

Devine Globe Technologies offers AI agent development and integration for software products. If you are preparing to add agents to a SaaS application, share the workflow, systems, and actions you want to enable. Those details provide a concrete starting point for discussing implementation scope and production requirements.