> ## Documentation Index
> Fetch the complete documentation index at: https://docs.baselayer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agents Acting for a Business

> How an agent proves which business it represents and which verified person is acting for it.

## Overview

In B2B, an agent may act for a business through a particular person. A supplier portal or procurement system needs to know both: which business the agent represents and which person is acting for it. Verifying that the business exists doesn't prove that the person may act on its behalf.

For example, an agent for Harbor Concrete reorders parts from Acme Supply's portal. Acme needs to know that the agent represents Harbor Concrete, which verified person is behind it, and that the person is verified to act for Harbor Concrete. Acme still decides whether to allow the reorder.

Key challenges:

* Identifying the business an agent represents
* Identifying the person behind the agent
* Confirming that the person is verified to act for the business
* Evaluating the business and person separately when a rule applies to both

With KYA, the agent presents a business credential and the acting person's credential.

* Baselayer mints the two together and binds them to the same agent key.
* It mints a business credential only when the operator link between the person and the business is `VERIFIED`.
* The credentials establish identity and the relationship between the two.

The site still decides what the agent may do.

| Role | Responsibility |
| - | - |
| Agent platform | Verifies the person and business, reviews their operator link if needed, and asks Baselayer to mint the credentials. |
| The site | Checks the credential presentation and decides what the agent may do. |

## How it works

> [!NOTE]
>
> The site's checks in the last two steps use the KYA SDK, which is coming soon. That code won't run until the packages are published.

**1. Verify the person and the business together**

The agent platform does one of these:

* Uses a Hosted Enrollment journey that collects a business.
* Sends a business verification to [`POST /issuance/identities/verifications`](https://docs.baselayer.com/api-reference/identities/start-a-direct-verification) with both the person and the business.

It includes the business's tax ID (`tin`) so the link can verify on its own.

The response includes an `individual_ref`, a `business_ref` and the link's status. See [Verifying an Identity](https://docs.baselayer.com/docs/verifying-an-identity.md).

**2. Check the operator link**

The link is `VERIFIED` when:

* A tax ID was provided.
* The IRS matched it to the business name.
* The business was verified against its state registry.

If a check fell short, the link is `UNDER_REVIEW` and its `shortfalls` say which.

**3. Review links that need a decision**

The agent platform:

1. Lists links with `status=UNDER_REVIEW`.
2. Looks at the evidence.
3. Approves or rejects each one.

Decisions apply only to the agent platform's organization. See [Who Can Act for a Business](https://docs.baselayer.com/docs/kya-who-can-act-for-a-business.md).

**4. Mint the business credential**

The agent platform asks Baselayer to mint for the person and the business.

The mint returns two credentials minted together: the business's and the person's.

Each carries only the fields allowed by the site's published scope.

A mint for a link that isn't `VERIFIED` is refused with error code `6300`. See [Minting Credentials](https://docs.baselayer.com/docs/minting-credentials.md).

**5. The agent presents the pair**

The agent signs both credentials with the same key and the same nonce. In the token exchange:

* The business credential goes as `subject_token`.
* The person's goes as `actor_token`.

**6. Verify the pair as one**

The site calls `verifier.verify(subjectToken, { actor: actorToken, scope })`, with the scope from its published profile.

If either credential fails, the whole presentation is refused. A business credential sent without its person is refused with `ACTOR_MISMATCH`. See [Business Agents](https://docs.baselayer.com/docs/kya-business-agents.md).

**7. Check both the business and the person**

Each credential carries its own checks.

* `claims.attests(key)` asks about the business only.
* `claims.actorAttests(key)` asks about the person only.

For any rule that should cover both, such as a clear watchlist result, require both.

> [!WARNING]
>
> If the site checks only `attests()`, a screened business lets through a person who was never screened.

The business and person carry separate verification results. A check that passed for the business didn't necessarily pass for the person. When a rule applies to both, the site must check both results.

```ts TypeScript theme={null}
const report = await verifier.verify(subjectToken, { actor: actorToken, scope });
if (report.accepted) {
  const claims = report.exchangeClaims();
  // attests() asks the business, actorAttests() the person. Require both.
  const cleared =
    claims.attests("watchlist_clear") && claims.actorAttests("watchlist_clear");
}
```

```python Python theme={null}
report = await verifier.verify(subject_token, actor=actor_token, scope=scope)
if report.failure is None:
    claims = report.exchange_claims()
    # attests() asks the business, actor_attests() the person. Require both.
    cleared = claims.attests("watchlist_clear") and claims.actor_attests("watchlist_clear")
```

## What each party sees

| Party | What they see |
| - | - |
| Agent platform | The person and business references, the operator link status, and the credentials Baselayer mints. |
| The site | IDs, verification results, expiry and shared fields, listed below the table. |
| Agent | A one-time nonce, then the site's token if the presentation is accepted. |
| Person | The verification flow when first enrolled. They don't repeat it for every presentation. |
| Baselayer | The identity verifications and mint requests. The site checks credentials in its own code. |

The site sees:

* A site-specific ID for the business (`claims.sub`).
* The acting person's site-specific ID (`claims.act.sub`).
* Separate verification results for each (`claims.verification.active_keys` and `claims.act.verification.active_keys`).
* Their expiry.
* Any shared fields.

## Recommended settings

| Setting | Recommendation |
| - | - |
| Tax ID | Include `tin` when verifying the business. When the IRS and registry match, the operator link verifies automatically. Without it, the link waits for review. |
| Preset | `b2b_ecommerce` shares the person's name, email and phone, and the business's name and basic registration details. See the note below the table. |
| Gating | For a rule that should cover both credentials, require `attests(key)` and `actorAttests(key)`. `attests()` alone checks only the business. |
| Officer match | Treat `officer_match` as supporting evidence in a review. It never verifies or holds a link on its own, because many states don't list officers. |
| Rejection | Rejecting a link blocks new business credentials for that pair until the decision changes. It does not revoke credentials already minted; revoke those yourself. |
| Sandbox | Test with a sandbox key. Sandbox and production links are separate. |

> [!NOTE]
>
> **Preset**
>
> * Use `b2b_ecommerce` only when those fields match what the site's KYA profile asks for.
> * A mint applies no preset unless it names one.
>
> See [Presets](https://docs.baselayer.com/docs/minting-credentials.md#presets).

## Next steps

* Verify the relationship: [Who Can Act for a Business](https://docs.baselayer.com/docs/kya-who-can-act-for-a-business.md)
* Mint the credential pair: [Minting Credentials](https://docs.baselayer.com/docs/minting-credentials.md)
* Check the pair at the site: [Business Agents](https://docs.baselayer.com/docs/kya-business-agents.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.