Public agent APIs and private business data

Long description

The public path sends approved service names, descriptions, and inquiry links to a read-only catalog. The private path sends customer records and job details through identity, business, record, and action checks into a scoped workflow. The boundary forbids private records in public responses.

Start with two kinds of information

A business website is meant to be discovered. Its service descriptions, public FAQs and ordinary contact routes can also be useful to software agents. Customer records, private documents and job details belong behind a different boundary. Decide which information you intend to publish before designing an API. Do not generate a public catalog by giving a model unrestricted access to private records and asking it to hide anything sensitive.

What a public catalog can contain

A simple catalog might list service names, descriptions, delivery options and a link to inquire. Its job is to explain the business. Keep it read-only: reading a service description should not book a visit, accept terms, charge a card or retrieve a customer order. OpenAPI provides a standard way to describe an HTTP interface, including its operations and security requirements. Documentation helps clients understand an interface; it does not enforce permissions. Source: OpenAPI specification.

A visible key cannot protect private data

If everyone can copy a key from a webpage, everyone can use it. Treat such a value as a public identifier, not proof that a visitor is allowed to access an account. For intentionally public data, a keyless read-only endpoint is often simpler, with caching and abuse controls appropriate to the site. Privileged provider keys must stay out of browser-delivered code. OpenAI’s key-safety guidance specifically warns against deploying API keys in client-side environments. Source: API key safety.

Private actions need separate checks

A private interface should establish who is calling and what that caller may do. Being signed in is only the beginning: the system must also check the business, the record and the requested operation. A permission to read a lead should not silently become permission to send that lead a message. For MCP connections, official guidance addresses token validation, scope minimization and the risks of passing tokens through to downstream services. Use a maintained authorization implementation and test unauthorized requests. Source: MCP security guidance.

Trace where the information goes

Ask for a plain-language data flow: source tool, application, model provider, storage and any destination. “Private” should describe access and handling under disclosed terms. It should not imply that no provider processes the data. For example, OpenAI documents different retention behavior by API feature and configuration. Review the actual endpoints and account settings used in your project rather than applying one blanket claim to every tool. Source: OpenAI data controls.

Follow a public request from beginning to end

Consider a fictional visitor asking an agent whether Cedar Desk Demo offers remote consultations. The agent reads an approved public service record and returns the description and inquiry link. It has learned a public fact. It has not signed into a customer account, checked a private appointment or authorized a purchase. Keep that distinction visible in the page copy and interface. A visitor should be able to understand which step merely reads information and which step would create a request or commitment.

Know when a question crosses the boundary

Now imagine the visitor asks, “What is the status of my setup job?” Answering that question may require private order information and proof that the caller can access it. A public service ID or an email address typed into a form is not enough on its own. The application needs an appropriate authenticated flow and permission check. Likewise, asking about on-site availability should not silently become a booking. A useful public response can explain how to begin an authorized inquiry without exposing anyone else’s appointment details.

Ask what can be copied or cached

Public information should be prepared with the expectation that it may be copied, indexed or cached. Do not place temporarily private details in the catalog because you expect to remove them quickly. Use a separate reviewed publishing record, then decide how corrections and retired services are reflected in both the human page and machine-readable response. If a business fact changes, check the actual public response after the change rather than assuming a dashboard edit immediately reached every cached copy.

A plain-language review for the owner

Before approving a catalog, read a sample response yourself. Can you explain every field? Would you be comfortable placing the same information on the public service page? Does any wording imply a guarantee, current booking slot or tested integration that has not been established? Ask the implementer to show the anonymous view separately from a private account view. Keep unresolved questions visible. The goal is an understandable discovery route with a deliberate boundary around customer-specific work.

Use a short launch checklist

Can an anonymous visitor see only approved public information? Can one business access another business’s records? Can a revoked connection still run queued work? Does an action require the right permission and, where needed, a specific approval? Does the log record what happened without storing secrets? These questions belong in implementation tests. InstallAI’s private workspace and authenticated agent interface are planned platform directions; a public catalog must not imply those capabilities are already live.