An employee signs into a company system. They can read customer records and update work in progress. Then they connect an AI assistant to that account.
The person is authenticated. The assistant can now request work through their access. But those are different questions: who is the person, what may the AI do, and is this particular action allowed?
This is the security problem I want to start with. Adopting AI should not mean treating the employee's existing access as a blanket permission for whatever an assistant asks to do. Nor should a policy written in a prompt become the boundary protecting company data.
IT and security leaders need a way to connect useful business knowledge without creating a special exception for AI. That takes trust architecture: an environment, defined identities and permissions, and an authorization decision outside the model.
Authentication is not AI authority
A successful sign-in establishes an identity. It does not settle every action that follows.
Consider a hypothetical request: prepare a customer update using CRM notes, recent email and an outstanding invoice. The person may be allowed to read those records. That does not automatically mean the AI should be allowed to change the invoice, send the update or access a different customer's information.
The requesting person's permissions and the AI identity's authority both matter. If either side does not permit the operation, a legitimate user request should not turn into broader AI access.
That is why a session-level decision is not enough. The next tool call can involve another record, another system or a different kind of action.
Check both sides of every tool call
Holiday is a secure business knowledge platform. It creates an independent, controlled environment where AI can use connected business knowledge through purpose-built APIs, with hard-coded AI boundaries enforced by software rather than prompts.
Every tool call is checked against both the AI identity's authority and the requesting user's permissions. The model can request an action, but Holiday makes and records the authorization decision in the application layer. The model does not grant itself access.
This is an important distinction from simply inheriting the permissions of whichever source application or employee account happens to be connected. Holiday governs AI access within its own environment. AI operating inside it uses approved, scoped connections assigned to its role rather than borrowing a person's credentials.
The business controls the environment and the permissions. AI operates within those boundaries. Access to useful context does not grant authority to take every action that context makes possible.
Connected knowledge needs an operating boundary
Business questions rarely stop at one application. A customer conversation can relate to a proposal, an invoice and work already underway. Keeping that context useful does not require giving every AI role unrestricted access to every underlying system.
Holiday brings approved information into a separate, single-tenant business knowledge environment. Its PostgreSQL database is separate from the source applications. Access, responsibilities, authority and escalation requirements can then be assigned to the people and AI roles using that environment.
A role should make the difference between reading a record and changing it clear. It should also make clear which decisions must return to a person. Those boundaries belong in software controls, not solely in instructions asking a model to behave.
An audit trail should explain the work
Permission checks are one part of the picture. Security teams also need to understand what happened after a request was made.
A useful review connects the instruction to the requesting person, the AI identity, the model used, the systems and records accessed, the actions taken and the outcome. When human review is required, the record should include the reviewer and approval or rejection, rather than leaving that decision outside the history.
Holiday's governance reporting follows work from instruction to outcome. This gives a security review something more useful than the final answer alone: an attributable record of the access and decisions behind it.
Ask for the deployment details, not a security slogan
Architecture claims still need evidence. Before approving an AI deployment, ask:
- Where is the authorization decision enforced, and can the model change it?
- Does each tool call check both the AI role and the requesting person?
- Which connections and credentials does the AI actually use?
- What can the audit record explain about access, approvals and outcomes?
- Which controls are implemented, and which depend on the proposed deployment?
The last question matters. Holiday uses Amazon Cognito for user authentication, but MFA enforcement and enterprise SSO federation are deployment-specific options, not settings we describe as enabled for every customer by default. Customers select a supported AWS region for their Holiday environment; AI processing locations also depend on the model providers they choose.
Those distinctions are part of an honest security conversation. A zero-trust principle mapping is not a certification, and choosing a hosting region is not a blanket promise about every AI provider's processing location.
Businesses should not have to weaken their security policies to make AI useful. Start with the security problem, establish who and what is allowed to act, and require evidence at every step.
Read Holiday's Trust & Security architecture, explore governance reporting, or bring your deployment questions to us.