OpenAI Frontier: identity and permissions for AI agents
OpenAI Frontier connects data, tools and agents through shared context. We analyse identity, permissions, memory, open standards and deployment risk.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 5 February 2026
- READING TIME
- 12 min read
- TOPIC
- AI Security
On 5 February 2026, OpenAI introduced Frontier, a platform to build, deploy and manage enterprise AI agents. The proposition extends beyond another chatbot: shared context from warehouses, CRM, ticketing and internal applications; a tool runtime; memory; evaluations; and a distinct identity with permissions and boundaries for every agent.
Frontier was designed to work with existing systems and third-party agents through open standards without forcing data migration. At announcement it was available to a limited customer set, with broader access planned over subsequent months. Business results in the launch post — such as reducing root-cause analysis from hours to minutes — are vendor case studies, not universal guarantees.
Agent identity matters more than model branding
An answer-only agent has limited blast radius. One that reads CRM, executes code and changes records is a workload identity. It needs its own principal, least privilege, short-lived credentials and complete action attribution. It should not inherit a human’s token or a shared API key.
OpenAI describes identity, permissions and guardrails, but implementation quality depends on target systems. If a CRM sees only one “Frontier integration” account, ten agents collapse back into one opaque identity. Context is also permission: an agent should not retrieve a whole warehouse for a one-customer task.
Memory and feedback add attack surface
Frontier can build memory from interactions and use feedback to improve quality. A stored instruction can persist an error or prompt injection. Memory needs provenance, TTL, versioning, review and deletion. Text from an outside document must not silently become a system rule.
Evaluate actions, not only answers: whether the right tool, minimum data and required approval were used, and whether the agent stopped safely. Test poisoned tickets, documents and tool outputs separately.
A minimum secure architecture
Use a tool gateway that validates schema, policy and budget. Reversible actions may be pre-approved; payments, deletions, publication and permission changes need a human. Correlation IDs should connect prompt, context, call, output and policy decision.
Separate local, enterprise-cloud and vendor runtimes. Decide which data may leave the region, where logs exist and how an emergency kill switch works. Our AI agent sandbox architecture provides a detailed pattern.
Frontier names the real barrier: model intelligence alone does not safely embed an agent in a company. Threat-model and test permissions end to end before production.
Action and approval matrix
Classify tools by impact. Reading public documentation may run automatically. Customer-data access needs a work context and purpose. Record changes require confirmation with a visible diff. Payment, deletion or role grants need a second person or an external workflow.
Approval must not carry between tasks. Consent to “prepare an invoice” does not approve sending it, much less changing bank details. The gateway should understand operation semantics and constrain parameters, not merely function names.
Controlling shared context
A semantic layer joining CRM, ticketing and warehouses is an attractive target. Documents should retain source ACL, classification, owner and date. Retrieval must not return information unavailable to the initiating user. Cache entries need tenant and policy-context isolation.
Test indirect prompt injection: a support ticket instructs the agent to retrieve other data and paste it into a reply. The agent should treat problem text as data, while DLP blocks an unauthorised flow even if the model proposes it.
An operational kill switch
Disabling the model may not stop queued jobs. Use central identity revocation, gateway shutdown and queue cancellation. Preserve traces, system-prompt version, model and policy after an incident. Otherwise investigation has an output without a cause.
Do open standards remove lock-in? They help protocol portability, while memory, evaluations, policy and data models may remain proprietary. Test export during the proof of concept.
KPIs that do not reward risk
Do not measure only automated case volume. Track correctly completed tasks, human interventions, reversals, policy violations, cost and time. An agent that completes more by skipping approval is not better. The dashboard should drill from business outcome to the exact trace and policy decision.
Primary source: OpenAI — Introducing OpenAI Frontier.
