Sentinel shipped two official apps this month: one for Slack, one for GitHub. Before writing either, I wrote down a constraint: each app gets the minimum permission that makes the feature work, and if a feature needs more than that, the feature waits.

The Slack app asks for exactly one scope. It can post messages to channels you explicitly pick, and that's the entire footprint: it can't read your messages, can't list your channels, can't see your members. The GitHub app goes further. It holds no API credentials at all. It consumes the webhooks GitHub sends it, and if you handed its server to an attacker, there would be no token inside with which to call GitHub about anything.

This wasn't a security posture I talked myself into afterward. It shaped what got built.

Whose workspace is it, anyway?

Most Sentinel customers are agencies and freelancers, which means the Slack workspace or GitHub org they're connecting often isn't theirs. It's a client's. When you ask a client's IT admin to approve an app, every scope on the consent screen is a question they have to answer on your behalf. "Post messages to a channel you choose" is a question that answers itself. "Read message history" starts a meeting.

An integration that's easy to approve gets approved. For the people we build for, the consent screen is part of the product.

Every scope is a liability you hold for someone else

The other reason is less visible but heavier. Whatever an app can access, its vendor must now protect. If our Slack app could read messages, then a breach of our infrastructure would be a breach of your client conversations, and no amount of encryption-at-rest changes that arithmetic. The only data that's perfectly secure in a breach is data you never had.

So the Slack app stores one webhook URL per channel, encrypted. The GitHub app stores a repo list and deploy metadata: commit shas, branch names, usernames, timestamps. Our whole sub-processor list fits on one page, and the security questionnaires that marketplaces make you fill out become short exercises in saying "no, we can't access that" over and over.

What this costs, honestly

Minimal permissions aren't free. There are features we can't build inside this constraint, and I want to name them rather than pretend they don't exist.

The Slack app can't thread a recovery message under the original outage, can't offer an acknowledge button, and can't answer a slash command, because all of that requires a bot token with broader scopes and standing infrastructure to receive Slack's events. The GitHub app can't post a commit status saying your deploy passed its post-deploy checks, because writing anything to GitHub means holding credentials to GitHub.

Some of those features are genuinely good, and some customers will eventually want them. When that happens, they'll arrive as a separate, clearly labeled opt-in, priced in permissions the same way everything else is priced in dollars, so the customers who don't need them never carry the scope. What won't happen is a quiet update where an app you approved for one thing starts asking for five.

There's an old idea in security called the principle of least privilege, and it's usually framed as protection for the system. I think of it more plainly: the consent screen is a contract, and an app that asks for exactly what it uses is keeping its word before it's installed.

If you want to check ours, both are live: Slack, one scope. GitHub, zero credentials. The permissions read like the marketing copy because they are the marketing copy.