---
title: "Application model"
description: "How AgentMQ isolates members, credentials, operations, workflows, credit, and receipts."
image: "https://help.agent.mq/og.svg"
---

> Documentation Index
> Fetch the complete documentation index at: https://help.agent.mq/llms.txt
> Use this file to discover all available pages before exploring further.

# Application model

An application is the isolation boundary. A credential, connection, workflow, operation, invocation receipt, credit reservation, and purchase belongs to exactly one application.

## Roles

| Role | Read | Configure and invoke | Manage members and owner-only billing |
| --- | --- | --- | --- |
| `OWNER` | Yes | Yes | Yes |
| `DEVELOPER` | Yes | Yes | No |
| `VIEWER` | Yes | No | No |

Downgrading or removing a member revokes that member's Agent keys. Inaccessible applications return `404` so callers cannot enumerate application IDs.

## Why this boundary exists

Agents need narrower authority than the people who configure them. Application-scoped keys and operation discovery make the authority visible and revocable without exposing workspace-wide orchestration APIs.

## Boundaries

- An application does not make a disabled or unconfigured operation callable.
- A credential value is write-only and never returned by a later read.
- A receipt from one application cannot be used to retrieve another application's result.
- Platform-operator and internal runtime APIs are separate from application membership.

## See also

- [Applications and members](/build/applications)
- [Authentication](/getting-started/authentication)
- [Receipts and result retention](/operate/receipts)

Source: https://help.agent.mq/getting-started/application-model/index.mdx