Malveon does not run an agent on your servers, ask you to export anything, or sit in the path of your code. It connects to the tools you already use over OAuth and reads signals from them. This post walks through what that connection actually does, what each one is authorized to see, and how the credentials are stored.
Malveon is in private beta. The connection layer described here is the real implementation; the product surfaces that sit on top of it are still filling in.
Why OAuth instead of agents or exports
There are three common ways to get data out of a tool: install an agent, export a file, or connect over its API. An agent means something new running on your infrastructure. An export goes stale the moment it finishes. OAuth is the third option: you grant a scoped, revocable token, and the tool itself reports what changed, when it changes.
It also keeps you in control. Every connection is something you authorize, see in your settings, and revoke in one click. Nothing about Malveon requires a migration or a change to how your team already works.
What happens when you connect a tool
The flow is the standard OAuth authorization-code exchange, with two details worth calling out.
- You click connect. Malveon builds the provider authorization URL with a specific set of scopes and a signed state value, then sends you to the provider to approve it.
- The provider redirects back with a short-lived code. The signed state is checked first, so a forged or replayed callback is rejected before anything else happens.
- Malveon exchanges the code for an access token, encrypts it, and stores it. From that point the connection is a token in a vault, not a password sitting anywhere.
What each connection is authorized to read
Scopes are the honest answer to the question "what can this thing see." Here is what Malveon requests, per provider:
- GitHub: repository, organization, and user-profile access, so it can see pull requests, checks, and deploy events.
- Jira: read access to work items (jira-work) and the users on them (jira-user).
- Linear: read access to issues and project data.
- Confluence: read access to pages, spaces, and search.
- Notion: access to the pages and databases you explicitly share with the integration.
- Google Docs: read-only access to documents and Drive metadata.
- Microsoft Teams: read access to channel and chat messages.
- Slack: a dedicated connection with its own handler, scoped to the channels you choose.
A note on honesty: a few of these grants are broader than read-only at the token level. GitHub repository scope, for instance, can technically write. Malveon behavior is read-oriented: it reads metadata, the titles, statuses, timestamps, and events, not your source files, and it does not post into your channels.
How your tokens are stored
An OAuth token is a credential. If it leaks, it is as good as a password. Malveon encrypts every stored token at rest with AES-256-GCM before it touches the database, so a database dump on its own does not expose a single usable token.
The OAuth state value is signed, which closes the cross-site request forgery gap that unsigned OAuth flows leave open. A callback Malveon did not initiate does not get processed.
What this connection does not do
- It does not read or transmit your source code.
- It does not write to your repositories or post to your channels.
- It does not require an agent, a proxy, or a change to your existing tools.
- It can be revoked from your settings at any time, which invalidates the token immediately.
Malveon connects to Slack, GitHub, Jira, Linear, Notion, and Confluence over OAuth, reads the signals that matter, and leaves your tools exactly as they are. The connection is yours to grant and yours to revoke.