Access Requests
Review unknown or unauthorized senders before they become participants
Access requests are the approval queue for Agent Network. They appear when an inbound sender tries to address an agent but Fruxon cannot route them through the participant graph yet.
An access request is not a separate account. It is a proposed change to the graph: create or update a participant, then bind that participant to the addressed agent.
When requests are created
Fruxon records a pending request when a message arrives through a participant-owned inbound route and one of these is true:
| Case | What Fruxon records |
|---|---|
| No participant matches the sender address | A proposed new Person participant with one channel. |
| A participant matches, but is not bound to the addressed agent | A proposed binding from that participant to the agent. |
The original message is dropped. Approval is the gate that lets future messages through.
Config-keyed inbound routes that cannot identify the addressed agent do not create agent-specific requests yet. Those are deferred until the product has an explicit agent-selection or mention flow for that shape.
Where to review
The same tenant-flat queue backs two surfaces:
| Surface | Use it for |
|---|---|
| Agent overview | Review requests for one agent with agentId and status=pending filters. |
| Network → Access Requests | Triage pending requests across the tenant. |
Approved requests do not need a permanent "approved requests" list. After approval, the participant and its binding are the source of truth.
Request details
Each request includes:
| Field | Meaning |
|---|---|
| Sender | Display name, provider, and provider-specific address observed from the message. |
| Integration config | The credentials envelope that observed the sender. |
| Agent | The agent the sender tried to address. |
| Matched participant | Present when the sender is known but not bound to that agent. |
| Conversation | Best-effort channel, chat, or thread name observed at request time. |
| Status | Pending, Approved, or Rejected. |
| Audit fields | Processor, processing time, optional note, and approved participant id. |
Approve a request
Choose the approval mode that matches what the sender represents:
| Mode | Use when | Result |
|---|---|---|
| Create new | The sender is a new person. | Creates a Person participant, adds the observed channel, and binds it to the agent. |
| Add to existing | The sender is another address for someone already in the network. | Adds the observed channel to the chosen participant and ensures the agent binding. |
| Bind only | Fruxon matched the participant, but that participant was not allowed to address this agent yet. | Adds only the participant-agent binding. |
Approval can optionally include an audit note. On success, Fruxon best-effort notifies the sender through the participant dispatcher that they can now reach the agent.
Reject a request
Rejecting stamps the request with the processor, time, and optional note. Fruxon does not send an outbound rejection message.
A future inbound message from the same sender can create a new pending request. Rejection means "no for now," not "block forever."
API
List (with agentId / status / participantId filters), fetch, approve, and reject access requests through the Access Requests API.
Next steps
- Agent Network — participant and trigger model
- Conversations — inspect observed provider threads
- Integrations — configure provider credentials