Apps and agents in ChatGPT: the interface does not define permission
OpenAI brought conversational apps, agent tools, and new API models together at DevDay. The useful skill is separating interface, data, action, authorization, and evaluation before entrusting a task.
On October 6, 2025, OpenAI introduced three product families at DevDay: apps appearing inside ChatGPT, tools for building agents, and new models available through APIs. Together, they moved conversation closer to external tasks; separately, they solved different problems. An app supplies an interface and connection, an agent organizes steps and tools, and a model generates or interprets content.
The distinction matters because a smooth conversation can conceal an architecture spanning several companies, credentials, and real-world effects. Asking for a playlist, searching for a home, and changing an enterprise system do not require the same permission. The durable skill is mapping the flow of data and actions before mistaking convenience for authorization.
An app inside chat remains a third party
The official apps announcement explained that ChatGPT could suggest an integration when relevant or activate it when the user typed its name. Spotify, Canva, Coursera, Figma, Expedia, Booking.com, and Zillow formed the initial group. Their interfaces could display playlists, maps, presentations, or video inside the conversation.
On October 6, those apps were available in English to signed-in Free, Go, Plus, and Pro users outside the European Economic Area, Switzerland, and the United Kingdom, wherever the partner service operated. The Apps SDK was offered in preview. OpenAI still planned to open app submissions for review and explain monetization later.
This dated snapshot prevents two errors. A global announcement does not mean availability in every region or plan. And an SDK open to developers does not mean any app can already be published. Verifying a feature requires recording date, territory, account, product phase, and distribution mechanism.
The conversation combines context from several origins
OpenAI said the first connection would tell users that certain data could be shared with the app developer. It required a clear privacy policy, minimum collection, and transparent permissions. That establishes a design intention; it does not replace checking which exact fields each integration receives and why it retains them.
A request may combine the user’s message, conversation history selected by ChatGPT, external account data, results returned by the partner’s server, and telemetry from both platforms. “Uses context” is too vague for an audit. The origin, recipient, purpose, retention, and deletion route should be named for each data item.
An embedded interface does not change who is responsible. A Zillow map or Spotify playlist may appear inside ChatGPT while still coming from the partner’s backend. Before sending sensitive information, users and builders should distinguish what OpenAI processes, what the third party receives, and which terms govern the connected account.
MCP transports capabilities; it does not grant trust
The Apps SDK was built on Model Context Protocol, an open standard for connecting models to tools and data. OpenAI extended it so developers could define logic and interfaces and connect their own backends. Standardization reduces integration work and makes it possible to describe tools in a common form.
A protocol does not decide whether a tool should run. It can express the existence of a search, booking, or update operation; policy must determine who may invoke it, with which arguments, against which resources, and after what confirmation. Confusing transport with authorization turns a technically correct connection into a risk.
A tool card needs its name, effect, input data, credential, scope, reversibility, and response. A read operation may run automatically when risk is low; a purchase, transmission, or deletion needs stronger controls. The distinction follows consequences, not how natural the message sounds.
AgentKit organizes a system but does not prove reliability
The AgentKit announcement grouped Agent Builder, Connector Registry, ChatKit, and new evaluation features. Agent Builder supplied a visual canvas with nodes, tools, guardrails, preview runs, and versions. Connector Registry centralized connections. ChatKit embedded conversational interfaces. Evals added datasets, trace grading, prompt optimization, and third-party model evaluation.
The launch stages were not identical. ChatKit and the new Evals capabilities were generally available to developers; Agent Builder was in beta; Connector Registry was starting a beta rollout to selected API, Enterprise, and Edu customers with an administrative console. Presenting the whole bundle as fully available would erase these distinctions.
A visual editor can accelerate prototyping and expose the workflow. It does not demonstrate correct performance on an unforeseen task. A guardrails library can detect specified inputs or personal data; it does not make every tool combination safe. Each control must correspond to a threat and be measured.
App, agent, and model are three layers
The app is the interaction point and service integration. The agent chooses a sequence: retrieve information, select tools, inspect results, and continue. The model proposes text, calls, or representations. Switching models may change quality and cost, but it does not repair excessive permissions or an irreversible tool.
The DevDay 2025 page separately announced GPT-5 Pro in the API and Sora 2 for video generation. It also reported more than 800 million weekly ChatGPT users and four million developers. These are OpenAI-reported platform figures, not users of each app or outcomes from a particular agent.
Distribution scale may attract services, but it does not establish adoption or quality. An app needs active connections, completed tasks, and abandonment measures. An agent needs success by case type, errors, and human corrections. A model needs quality, latency, and cost on a defined test set. A platform metric cannot replace product metrics.
Permission is designed around the effect
A simple matrix crosses tools and data. For each cell, record whether the operation reads, proposes, creates, changes, sends money, or deletes; which identity acts; and whether it is reversible. Then assign authorization: always permitted, scope-limited, confirmed each time, or forbidden.
Confirmation should describe the actual effect, not display a generic button. “Send this email to these two addresses,” “book at this price,” or “replace this file” supports an informed decision. If the agent changes the recipient, amount, or resource, the prior authorization no longer applies. Confirming a broad intent does not validate every argument the model invents.
Credentials should also have minimum scope. An integration that checks availability does not need cancellation permission. An agent that drafts a reply does not need to send it. Separating preparation from execution creates a review point and reduces harm from a malicious instruction embedded in a page or document.
The trace reveals where failure occurred
An outcome evaluation says only whether a task finished. Trace grading observes each step: which context the model received, which tool it selected, which arguments it produced, what the service returned, and why it continued. This separates a reasoning mistake, bad data, authorization failure, and an unexpected external response.
The test set should include ordinary cases, missing data, conflicting instructions, injection attempts, slow responses, duplicates, and operations requiring confirmation. It should measure success, unnecessary calls, unauthorized actions, cost, and recovery. A quick demonstration shows ease of assembly; a repeatable suite shows behavior.
Versioning the workflow, instructions, tools, and models makes each change comparable. If final-task success improves while improper actions rise, the change is not a net improvement. Production logs should support investigation without retaining more sensitive content than necessary, and should mark human intervention.
The platform is audited as a chain
The path begins with the request and continues through context selection, model decision, tool call, external service, and visible response. At every boundary, record data, identity, permission, validation, logging, and output. If a box remains unknown, the system is not ready for high-consequence work.
Apps and AgentKit showed a clear direction in October 2025: making conversation an interface to software and making workflows easier for developers to assemble. The useful conclusion is not that ChatGPT instantly became an operating system. It is that one interface could join layers that retained separate responsibilities.
The transferable skill is refusing to authorize by appearance. For any conversational app or agent, separate interface, data, decision, tool, and effect; then require permission and evaluation at the right layer. Conversation can make use simple. Only that map makes control understandable.
This article was produced with artificial intelligence under human editorial oversight.
