OpenAI and Enterprise AI Security: What CIOs Must Get Right Before Deployment
Your AI assistant has passed security testing. Your OpenAI deployment meets the required platform controls. Your team is ready to move into production. But, can you explain exactly which internal systems the AI assistant can access, what information the AI assistant can retrieve and which actions the AI assistant is allowed to take? If the answer is unclear, you may have secured the platform without securing the system built around it.
That is where enterprise AI security is decided. OpenAI’s business products come with platform protections: encryption, independent audits and a pledge not to train on business data by default. Those protections cover the providers side of the system. They do not decide who in your organisation can see what tools the AI assistant can call or what happens when a malicious instruction hides inside a document the AI assistant reads. The AI assistant does not have visibility beyond what you allow it.
For CIOs the question that matters is whether the system your teams build on top of OpenAI is secure. Answering that question means separating what OpenAI controls from what your enterprise owns and getting seven areas right before anything reaches production data. The AI assistant must operate within those seven areas.
Most of the time, enterprise AI security reviews are conducted by the vendor. Procurement reviews the vendor’s documentation regarding trust, audits of their encryption standards, etc., and then gives approval.
While this process is critical, it is typically as far as the review goes. The risks that occur in production typically exist because of a number of factors. An assistant that is connected to a document repository will be able to display any file that is allowed through the repository’s permission settings, including documents that may have been shared many years ago. An agent that has write access to a CRM can modify records based on information contained within an email. A logging system that nobody monitors provides zero evidence if something goes wrong.
All three of these examples represent a decision regarding design and governance made by the enterprise and not an issue that the model provider can manage. A vendor’s SOC 2 report demonstrates the vendor’s controls and auditors will inquire about your connector scope, agent permissions and how you handle logs.
OpenAI has put out enterprise-level commitments regarding Enterprise Privacy, Security and Privacy. There are several main ways that OpenAI controls its own operations:
While these are strong foundational elements, the remainder of this article will discuss controls that reside on the enterprise side of the line.
Every AI interaction must be able to be associated with a specific user and their granted rights. The authorization of these rights are supported by both Single Sign On (SSO) using SAML, and through applications which leverage pre-existing authorizations; however, users will likely have to re-authorize themselves for each application they connect to.
When SharePoint or Google Drive rights have been provided too broadly, the AI may be able to demonstrate this vulnerability at scale. Rights management should be integrated into your Identity Provider (IdP). Workspace memberships should be aligned with IdP groups. Offboarding should also remove user access immediately.
Rights for utilizing assistants, building agents, enabling connectors and reviewing audit logs should be separated. Dedicated projects and keys should be used for API workloads. Secrets used in API workloads should be stored securely. Secrets should be rotated on a regular basis. Rights should be reviewed prior to connecting sensitive repositories.
The use of data by the AI provider (OpenAI) is covered under their Data Protection Commitments. It is up to the company to decide what data can be sent to the AI application from its employees and internal applications.
Companies should categorize their data into different classes and then determine which applications will have access to the data. In some cases, companies may want to redact or remove any personally identifiable information (PII) contained within the data prior to sending it to the model. Also, companies should ensure that when the data is retrieved using the retrieval feature of the model, only the specific fields necessary to complete the task are returned. Companies must also confirm contractually that all applicable regulatory requirements are met, such as Business Associate Agreements (BAAs) for protected health information (PHI) that is subject to HIPAA regulations, Data Processing Agreements (DPAs) as required, and any additional data residency requirements.
Every one of the credentials an AI assistant uses to perform tasks such as updating customer records, sending emails, processing refunds, etc. has potential security risks associated with them. OpenAI has provided methods of allowing users to enable applications, however, companies will still have the ultimate responsibility for maintaining the proper safeguards and permissions associated with all of the company’s tools.
Identify each tool that has a name assigned to it by its owner, its intended use, and its level of risk. Always assume that the tool should have the least amount of access possible (i.e. read-only), isolate high-impact actions into separate tools that are limited in scope, and only provide the necessary permissions to service accounts. Implement value limitations, recipient limitations, and other safeguards in the code of your application and do not rely solely upon prompting.
Untrusted content that tries to change what an AI system is supposed to do is called “prompt injection.” Untrusted content can come into the system from email, PDF documents, web pages, help desk tickets, or customer relationship management (CRM) records. Untrusted content may cause the AI agent to make unauthorized tool calls and/or disclose confidential information. The best way to prevent untrusted content from changing how the AI system should operate is to keep it away from developer instructions that are privileged.
In addition, when you get data back from the AI system, you need to check if the fields in your output have been validated. You also need to ensure that the outputs of one step of a workflow are properly formatted and passed along to subsequent steps in order to minimize the possibility of harmful instructions being spread throughout the workflow.
Every artificial intelligence process does not need to have the same amount of oversight. Having to approve every single process will create an obstacle to productivity; conversely, having no approval process at all can increase potential risks. Classify the impact of each action along with its ability to be reversed. Reading a knowledge base article will probably not need approval.
However, approving email communication with customers, updating customer data in systems, and processing refunds could require explicit authorization. Provide the approver(s) with specific details about which tool was used, what parameters were set for use, and who the recipient of the decision is.
Finally, authorize those that own these high-risk processes to be able to make final decisions on them.
If you cannot determine how an agent was able to access and do something, it will be very difficult to investigate any incident or show compliance. OpenAI has provided audit-logging capability to eligible ChatGPT business & education users; however, application specific activity needs to have its own logging.
Log all results from retrievals, tool calls, approval decisions and user identities in your own application logs. Provide correlation IDs for each run of an agent, connect related data points to your SIEM, create alerts when there is abnormal behavior or high risk actions occur. Provide the security team with the responsibility for reviewing logs and investigating all incidents.
Retention settings in OpenAI vary by product and endpoint. ChatGPT workspaces that are eligible can set up administrative retention settings. API data can be kept for as long as 30 days under the applicable default retention policies. If you meet the criteria and have approval, then you will be able to utilize Zero Data Retention. Before launching your project, make sure to agree upon the appropriate retention timeframes with your legal team, security team, and records management team.
In addition, consider where your data is being stored. Data being stored outside of OpenAI (i.e., prompts, outputs, embeddings, vector databases, application logs) all require their own retention, deletion, and legal hold policies.
Establishing security controls prior to deploying an AI agent is critical. Maintaining these controls while the AI agent evolves is equally important.
An AI agent’s access rights may change; new tools may be connected; workflows may extend beyond their initial scope to include other enterprise systems. Model or application updates also create opportunities for new types of failures. A security review performed at the time of deployment will not address all of the changes that follow.
This is why Enterprise AI requires more than a single-deployment checklist. Enterprise AI requires a lifecycle approach that integrates development, governance, operational oversight and continuous improvement.
Airo utilizes agenTriniti for AI Use Case Lifecycle Management. It is a lifecycle approach designed using three primary components: Build, Manage, and Continuously Upgrade. The purpose of this approach is to enable enterprises to manage AI agents as operational business assets instead of viewing each deployment as an individual project.
For CIOs, the practical consideration is if the enterprise can define clear lines of responsibility, implement and verify the required controls in both the underlying platforms and enterprise systems, evaluate the effectiveness of the agents, and conduct ongoing reviews of all changes during an agent’s lifecycle.
The objective is not merely to deploy an AI agent in a manner that protects against unauthorized access. The objective is to develop the discipline necessary to operate and enhance it in a responsible manner over time.
Before you put an OpenAI-powered assistant or agent into production data, your team needs to verify the following:
Securing an enterprise AI deployment requires more than validating the AI provider. Organizations must also verify how identity, data access, connected tools, approvals, monitoring, and retention work together across the complete solution.
Addressing these requirements before production helps organizations identify control gaps early, reduce avoidable deployment risks, and establish clearer accountability for AI-driven actions.
Airolabs’ Enterprise AI Advisory and AI Governance experts help CIOs and security leaders assess AI readiness, identify gaps in enterprise controls, and define the safeguards needed for responsible deployment.
Preparing to connect OpenAI-powered assistants or agents to enterprise data? Talk to Airolabs about a pre-deployment AI security and governance review.
By default, no. OpenAI states that data from ChatGPT Business, Enterprise, Edu, Healthcare, Teachers, and the API Platform is not used for training unless the customer explicitly opts in, for example through feedback mechanisms.
Provider controls are the protections OpenAI operates, such as encryption, audited infrastructure, and contractual commitments. Enterprise controls are the decisions an organization makes about how it uses the platform, including access, data classification, tool permissions, approvals, logging, and retention.
Prompt injection happens when untrusted text or data entering an AI system tries to override the system’s instructions. It can lead to data exfiltration through tool calls or unintended actions. Mitigations reduce the risk, and OpenAI notes they do not remove it entirely.
Except for certain endpoints, OpenAI may retain API inputs and outputs for up to 30 days to provide the service and identify abuse. Zero data retention is available for eligible endpoints with a qualifying use case.
It is an important input. It covers OpenAI’s controls only, so the enterprise still needs to evidence its own controls over identity, connectors, agent tools, logging, and retention.
