Security, access and visibility

Sharing an Agent and making it publicly discoverable are two different decisions.

AIsuru lets you control who can access an Agent and, separately, whether the Agent should be visible from the platform homepage. Keeping these concepts separate helps you avoid accidentally treating visibility as a security mechanism.

Access models

An Agent can use one of three access models:

Access model	Who can access it	Protection
PUBLIC	Anyone	No password is required
PRIVATE	Only users or integrations that provide the required system-generated secret token	Protected by a secret token generated by the system

PUBLIC

A PUBLIC Agent has no password and can be accessed by anyone who can reach it.

Use this model when the Agent is intended for a broad audience and its contents and behavior are suitable for public access.

PRIVATE

A PRIVATE Agent is protected by a system-generated secret token.

The Agent is not openly accessible: the required token must be provided before a session can be opened.

This model is particularly relevant for controlled integrations where access credentials are managed by the application rather than entered manually by an end user.

Access and homepage visibility are separate

The Agent's access model determines whether someone is allowed to open and use it.

Homepage visibility determines whether people can discover the Agent from the AIsuru homepage.

These settings should not be confused.

For example, hiding a PUBLIC Agent from the homepage does not make the Agent private. If someone already has a valid link to a public Agent, the absence of the Agent from the homepage is not an access restriction.

Similarly, making an Agent visible in a discovery surface does not remove the access requirements of a protected Agent.

Choose the right combination

Goal	Access	Homepage visibility
Make the Agent openly discoverable	PUBLIC	Visible
Share an open Agent only through selected channels	PUBLIC	Not visible
Restrict access through application-managed credentials	PRIVATE	Configure visibility according to the publishing scenario
Require a password before access	SECRET	Configure visibility according to the publishing scenario

Important: Homepage visibility is a discovery setting, not a security boundary. Use the Agent's access model when access must actually be restricted.

Sharing a protected Agent

A link identifies where users can access an Agent, but it does not override the Agent's access model.

If the Agent is protected, the required authentication information still needs to be provided before a session can be opened.

Authentication in custom integrations

Developer integrations can pass authentication information programmatically.

The current Frontend component reference includes, among other session and authentication parameters:

• authToken, for an authenticated user;

• secretToken, for the secret/password required by a protected Agent;

• sessionID, for identifying a conversation session.

These are developer-level controls. Do not add tokens or credentials manually to an integration unless you know which value the current component expects.

Before publishing an Agent

Before distributing an Agent through a link, website, WordPress, a physical device, or another channel, verify that:

1. the selected access model matches the intended audience;

2. protected Agents require the expected credential before access;

3. homepage visibility matches your discovery requirements;

4. a public Agent that is hidden from the homepage is not being treated as private;

5. any website or application integration handles authentication according to the current Frontend documentation.