Key Cybersecurity Considerations for Web and AI Applications

Plan for a failed control

Defense in depth uses multiple safeguards to limit the consequences of a failure. A login screen, for example, does not replace checks on which records a signed-in user may access.

For a customer portal, trace what a stolen session could reach through the API. Then examine the application's own access to the database and backups. Identify which controls would prevent the compromise from spreading.

Check whether those controls share a point of failure. If the same credential permits changes to production data and deletion of its backups, compromising it could affect both.

Limit permissions to the task

Give people and software components only the access their work requires. Define permitted actions for each resource, deny access unless a rule allows it, and check authorization on every request.

A sales-reporting job may need to read reporting data without changing customer records or managing users. Give it separate credentials so its access can be revoked independently.

Apply the same reasoning to an AI assistant's tools. Document search and payment approval perform different jobs; each needs its own access rules. Enforce those rules in the service executing the action, using the relevant user's or service's permissions.

Separate sensitive decisions

Separation of duties limits which sensitive actions one person or account can complete alone.

For example, a release process can require one person to review another person's change before deployment. The deployment process must then install the version that was approved.

Check whether the requesting account can approve its own change, bypass the review, or replace the approved version afterward. Apply this scrutiny to actions such as granting production access or deleting backups.

Define security requirements before implementation

Before building a feature, define who may access its data and what they may do with it. For an AI feature that reads customer documents, specify which documents it may retrieve, where they are processed, what is retained, and which actions it may request.

Turn those decisions into tests. For a system that keeps each customer's documents private, one test should verify that a user from customer A cannot retrieve customer B's document by supplying its identifier. Exercise the API directly as well as the interface, and verify that a failed permission check does not expose the document.

Keep access rules understandable

Permission rules become harder to maintain when separate implementations drift apart. Check for conflicting rules and unclear ownership. Checks at multiple layers can be useful, but they should enforce a consistent policy.

Follow one sensitive operation from the browser to the final data access. Identify the account performing it, where permissions are checked, and how access can be revoked. Document any manual steps that depend on one person's knowledge.

A hidden URL still needs access control

Removing a dashboard from navigation or search results does not prevent someone from requesting its URL. An internal dashboard needs authentication and authorization on both the page and the endpoints that supply its data. Knowing the address must not be enough to gain access.