The three kinds of key
Member keys, service keys and the admin MCP key: when to use each, who issues them, where, and how to revoke them.
A key is the secret string an AI assistant uses to get into CoreSkill. There are three completely separate key systems: a key from one system never opens another system's endpoint, not even if you paste it in the wrong place.
| Kind | Prefix | Used for | Connects to |
|---|---|---|---|
| Member keys | cek_ | One specific person's AI assistant | the business hub |
| Service key | csk_ | Machine-to-machine integrations, not tied to a person | one specific server |
| Admin MCP | cmk_ | A manager's AI assistant, administering on their behalf | the management endpoint |
Which one do you want?
Almost always a member key. One key per person, each person sees exactly the skills their department may read, and revoking cuts off exactly that person. Reach for a service key only when the caller is a system rather than a human being.
Member keys, the ones you use every day
Open Member keys in the sidebar. There are two buttons:
- Issue key
- For one person. Pick the Member, set a Key name (after the machine they use:
Laptop,Office PC), choose an Expiry. - Issue for a department
- For every active member of the department who doesn't have a key yet, up to 50 people at a time. Sub-departments are not included, so do each of those separately. Anyone who already has a key is skipped, so pressing it again is safe.
The Expiry field offers: No expiry (the default), 7 days, 30 days, 90 days, 180 days, 365 days. An expired key stops working on its own, which is handy for contractors and trials.
A key is shown exactly ONCE
Right after you issue it, the amber Copy this key now card appears. Leave the page and it can never be read again. The system stores only a hash, never the real key. Lose it and your only move is to revoke and issue a new one.
A department issue also gets a Copy all as CSV button, so you can paste the list into a spreadsheet and send each person their own line.
Each person holds at most 5 active keys. Past that you get The key limit here is 5. Revoke or delete an old key first.
Changing department does not mean reissuing keys
A member key is pinned to a person, not to a server. The set of skills it can read is recomputed on every single call, from that person's current department. Move someone from Marketing to Sales and their AI switches skill sets right away, still on the same old key.
Letting members issue their own keys
Go to Business settings → turn on Members can issue their own keys. Once it is on, a Member who opens My access sees an Issue myself a key button.
With it off, only Owners, Admins and Managers issue member keys, and members see the line Self-service keys are off in this business. Ask your manager or an admin for one.
Turning this on takes a lot of busywork off managers: someone who loses a machine revokes the old key and issues a new one on the spot, without waiting for anybody. In exchange you give up one control point. For a team under a few dozen people, turning it on is usually worth it.
Revoke and delete
Every key row has two buttons. Revoke keeps the row in the list with a Revoked badge, so you can still reconcile old log entries against it. Delete removes the record entirely.
Prefer Revoke over delete. Revoking cuts access immediately and still leaves a trail; when someone later asks "what did that key read", you still have an answer. Delete only when the list has grown too long to work with.
Calls made with a revoked or expired key are still written to the log, with status Denied. That is how you spot a leaked key that is still being tried.
Service keys for machine integrations
Only an Owner or an Admin can issue one. Open a server → the Keys tab → New key or Issue in bulk (one name per line, up to 20 at a time).
- This key is pinned to exactly one server: a key for server A calling server B is refused.
- At most 200 keys per server.
- It is tied to no person, so the log knows the key name but not who is behind it.
- A Manager can run a server but cannot issue service keys. Member keys are what they hand out.
Don't use a service key where a member key belongs. One key shared by a whole department means revoking cuts everybody off at once, and the log can never tell you who read what.
Where the key goes in the config
Prefer Authorization header (recommended). Every snippet in the Connect guide does it that way.
Only put a key in the URL when you have to
Some clients cannot send custom headers. For those, CoreSkill offers an address with the key tacked onto the end of the path. The key then sits in the access logs of your proxy and your server, so treat it as half-public. Use it only when nothing else works, and give that key a short expiry.
Quick reference
| Member keys | Service key | Admin MCP | |
|---|---|---|---|
| Issued on page | Member keys, My access | server → Keys tab | Admin MCP |
| Who can issue | Owner, Admin, Manager (own branch), Member (if enabled) | Owner, Admin | Owner, Admin |
| Ceiling | 5 active / person | 200 / server | 10 / business |
| Bulk issue | 50 / batch (whole department) | 20 / batch | no |
| Can set an expiry | yes | yes | no |
| Can write data? | no, read only | no, read only | yes |