Secure enterprise AI begins with the system around the model

The most useful security habit I brought from Airbus, space programs, and 5G security research into enterprise AI is quite plain: inspect the complete path.

Secure enterprise AI means that the data, identities, permissions, models, tools, actions, providers, and failure behavior of a defined production system are designed and tested together. A vendor can protect its model endpoint. That does not prove that a retrieved document reaches the right user, that an agent cannot call the wrong connector, or that a failed approval leaves a trace an operator can investigate.

The unit of security is therefore the deployed system and its exact version. The model is one component inside it.

A secure model can still sit inside an unsafe path

Enterprise AI security discussions often begin with the provider. Where is the model hosted? Does the provider train on customer data? Which certifications does it hold? Those questions matter. They cover only part of the path.

Imagine an event-company assistant that reads a project workspace, summarizes client changes, drafts a supplier email, and waits for approval. The model provider may meet the buyer's requirements. The application can still disclose another project through faulty retrieval, expose a connector key in the browser, accept instructions hidden inside a document, or send the approved draft to the wrong account.

None of those failures is fixed by changing the model name.

NIST's Generative AI Profile makes a similar distinction between model-level, application-level, and use-case risk. It also treats governance, pre-deployment testing, provenance, and incident disclosure as connected parts of risk management. The UK National Cyber Security Centre's guidance follows the system across design, development, deployment, and operation.

That lifecycle view is useful because an AI system keeps changing after launch. Model versions move. APIs change. New users arrive. A permission that was correct in August may be wrong in November.

Define the production boundary before choosing controls

I use a simple test. If a team cannot draw the system boundary on one page, it is too early to call the system secure.

The drawing should name the business result, the authorized users, every source and destination, the data categories, the model and service providers, and the actions the system may request. It should also show which identity touches each component and where information is stored, copied, or logged.

Compare these two descriptions:

We use enterprise AI to help operations.

This system prepares a daily project-change brief for production managers. It reads approved records from the project workspace, cannot access commercial HR folders, and may draft a supplier email. Sending requires an authenticated project owner. If a source is unavailable or two records conflict, the system produces no complete brief and routes the item for review.

The second description can be assessed. It gives security, operations, and the users something concrete to challenge.

Five control planes make enterprise AI reviewable

Compsia assesses a production path across five control planes. The names are less important than making sure none disappears between teams.

This model keeps ordinary software security in the room. Secrets, dependencies, authentication, logging, backups, and incident response still apply. AI adds uncertainty and new ways for untrusted input to influence behavior while the old disciplines remain.

What building Skybridge changed in our security work

One internal review of Skybridge found four small-looking issues with very different consequences.

A public webhook could trigger a full model run without a rate limit. A third-party request had no hard timeout. An agent-supplied connector path could escape the intended application path within the same workspace. A usage-control failure was allowed to fail open for continuity, but it produced no operator signal.

The fixes were ordinary engineering: rate-limit before database work, add bounded timeouts, reject path traversal and encoded escapes, and count every fail-open event in monitoring. The interesting part was where the problems lived. None sat inside the language model. They appeared at the edges where a model met cost, networking, integrations, and operations.

That review changed the questions we ask. “Is the model safe?” became “What can this request reach, what can it cause, and what will we see when a control refuses or fails?”

The OWASP prompt-injection guidance supports that broader approach. It recommends least privilege, output validation, human approval for higher-risk operations, separation of untrusted content, and adversarial testing. A stronger prompt helps as one layer; the surrounding permissions and tests carry the rest of the security design.

Test the behavior at the boundary

Security requirements become useful when written as observable behavior.

Do not write “the agent must respect permissions.” Write a test in which a user asks for a document outside their approved project and the retrieval layer returns nothing. Record the identity, source, request, result, and expected denial.

Do not write “consequential actions require approval.” Test an expired approval, a second approval attempt, a changed recipient, an unavailable connector, and a replayed request. The result should be defined before the test runs.

Prompt injection deserves the same treatment. Place conflicting instructions inside an email, document, or web page the system is asked to review and condense. The system should treat the content as evidence, preserve the owner's task, and remain inside the tool and action boundary. Because perfect prompt-injection prevention is not currently a credible promise, the surrounding permissions must limit the consequence of a model mistake.

Seven questions to ask before production

Use these questions on one real system rather than on the company's whole AI ambition:

1. What business result and operational perimeter does this version own?
2. Which data categories, sources, copies, logs, and providers are in the path?
3. Which human and service identities can access each part?
4. Which actions are permitted, approval-gated, or prohibited?
5. What happens when information conflicts, a provider fails, or an action is replayed?
6. Which tests prove access boundaries and failure behavior in a production-like environment?
7. Who can pause, roll back, investigate, and retire the system?

A vague answer is useful information. It reveals where the architecture or ownership is still unfinished.

Secure enterprise AI remains an operating decision

Every material change reopens the question of whether the previous evidence still applies. The release record should travel with the deployment: scope, data, providers, permissions, actions, tests, fallback, approvers, and known limits.

When any material part changes, the owner decides whether the previous evidence still applies. Monitoring then needs to show more than uptime. Tool calls, refusals, unusual consumption, connector failures, approvals, and policy violations all affect whether the system is operating inside its accepted boundary.

This is why Compsia treats security as part of designing and operating a complete AI production system. We narrow an unsupported path before connecting real customer data. The buyer receives a system defined around one result, with Skybridge access included for the agreed use and supervision. The security statement stays attached to that exact system.

If you are assessing a candidate operation, map one production perimeter before comparing models or vendors. A good boundary makes every later question sharper.

Questions enterprise leaders ask

Is an enterprise model automatically secure?

No. Provider controls can protect the model service, while the application still introduces risk through retrieval, integrations, permissions, logging, output handling, or actions. Assess the full deployed path.

What is the biggest enterprise AI security risk?

There is no universal answer. The most material risk depends on the system's data, authority, users, and consequences. Excessive permissions, unsafe retrieval, prompt injection, sensitive output, and weak failure handling are recurring classes worth testing.

Does human approval make an AI agent safe?

Approval can reduce action risk when the approver is authenticated, sees the material context, and controls the exact action. Excessive data access, missing retention rules, insecure credentials, and bypassable approval paths require their own controls.