Every control that limits what FirstIgnite reaches lives in your Minuet instance, not in FirstIgnite. Between them you can scope the integration from everything down to a single category of technology.
1. The Minuet user the integration runs as
The most important one, and the one people overlook.
FirstIgnite connects as a Minuet user your administrator chooses. That account's own record and field permissions decide what every API call can return. Narrow the account and you narrow the integration.
The trade-off is that permissions this account lacks show up as things that quietly don't work rather than as a clear error. If you narrow it, note what you narrowed. A missing permission on a single field can be enough to empty a whole list.
2. Record Access Control, for excluding specific technologies
This is the supported way to keep particular technologies out of FirstIgnite entirely: confidential disclosures, already-licensed work, anything sensitive relative to an existing licensee.
Your Minuet administrator assigns a security group to the records you want to exclude, then removes that group from the account the integration runs as. Those records become invisible to it and drop out of FirstIgnite's technology list. It's configured in Minuet's security-group settings, and Inteum support can walk an administrator through it if they haven't set one up before.
It's per record and yours to change at any time. FirstIgnite plays no part in it.
3. The Endpoint Access Group, for declining capabilities
Each endpoint you grant enables a specific capability. Decline one and that capability is unavailable. No fallback, no alternative route.
If you don't want FirstIgnite writing summaries back to your technologies, don't grant the technology write endpoint. If you want it to read but never create contacts, leave the contact create endpoint out. Each entry in Minuet API endpoints required by FirstIgnite says what stops working without it.
You can also leave the endpoint granted and switch the corresponding operation off on FirstIgnite's side. That's a lighter-weight version of the same decision, and a FirstIgnite team admin can reverse it without involving Minuet. See What each Minuet feature needs, and who can turn it on.
4. Hiding fields
These work at different levels:
Field permissions in Minuet stop the data leaving your instance. If the account can't read a field, FirstIgnite never receives it.
Additional Fields visibility in FirstIgnite controls which of your user-defined fields appear in FirstIgnite and feed into AI output. FirstIgnite applies it after fetching the data, so it's a presentation control rather than a data control. It's instance-wide, never per record.
For "this technology must not be visible", use Record Access Control. For "this field should never leave Minuet", use field permissions.
What's bounded by default
Even with everything granted, the integration is narrower than a full database connection:
Browsing the portfolio asks for 22 columns, not the whole record. See What FirstIgnite reads from a Minuet technology.
Documents transfer only when a person selects one.
Remarks marked private in Minuet are never returned by the API.
Agreement financial fields are never requested.
There is no bulk import. Reads are paginated and on demand.
FirstIgnite has no privileged access to Minuet. It's one account, configured by you, that you can revoke at any time.
Turning it off
Revoking the API client or removing its Endpoint Access Group cuts access. It takes effect when FirstIgnite's current access token expires, and needs nothing from FirstIgnite.
If something isn't working, see Troubleshooting the Minuet integration.