MCP for people operations: useful access without a shared super-token
Personal token lifecycle, hashed storage, expiration, revocation, current user scope, tools rather than direct database access, and when a direct integration is better.
What MCP changes
MCP lets an external AI client call product tools. For people operations, that can be useful: ask for your PTO balance, read a visible document, save a self-review draft, or request access without leaving your AI client.
The risk is obvious. A shared token with broad access would turn the AI client into a hidden administrator.
Tie the token to a person
A safer model ties each token to the person who created it. Perelan MCP uses personal tokens that inherit the owner's current access. The token does not become a new role.
Store a hash, not plaintext
The plaintext token should be shown once. The server can store a hash and compare future bearer tokens against it. This means a database row is not itself a reusable secret.
Keep tools scoped and explicit
MCP tools should expose product actions, not direct database access. A tool can request time off, read visible documents, or list requestable apps because the owning service still rechecks permissions.
Revoke and expire
Tokens need expiration, revocation, and live allowlist checks. If someone loses MCP eligibility or leaves the company, future calls should fail.
Choose MCP versus a product integration
Use MCP when a person wants their own scoped AI client to work with Perelan. Use Slack, Linear, incident.io, or Telegram when the workflow belongs in a specific operational tool.
Next step