Integration security: guardrails on every connected tool
Proofsource connects to your CMS, repos, analytics and social accounts, so it is built to be trusted with them. Every permission it asks for has a stated use. Any change it makes in a connected tool happens only after your approval, only in ways listed for that tool, and is recorded on the fix and in your audit log. Keys stay encrypted, and your org can limit which hosts Proofsource may call.
| Permission | Used for | Only changes made |
|---|---|---|
| Publish pages | Publishing a fix you approved | Create or update a fix page you approved; roll it back |
| Read posts | Checking your content | None |
| Read pages | Checking a fix | None |
| Roll back a fix | Undo a publish you approved | Take down the page it published |
Integration security and guardrails, in short
The facts, ready to quote.
- Listed writes
- For each integration, the only changes Proofsource may make are listed; anything else is refused before the tool is called.
- Approval first
- Writes happen only after a person's yes on that fix, or your own Autopilot setting.
- Audit
- Every write is recorded on the fix's timeline and in the org's audit log: who approved, what was written, where.
- Keys
- Tokens and keys are encrypted at rest and read only by the code that makes the listed call.
- Host allow-list
- Your org can list the hosts Proofsource may call.
- Sign-in
- SAML 2.0 and OIDC single sign-on, Google sign-in, or an email code. No passwords.
Integration security, explained
Any tool that fixes your AI visibility needs access to the places your brand lives: your CMS, your code repository, Search Console, your social accounts. Most integrations ask for broad permissions because the vendor's options are broad. The risk is not the permission itself; it is what a tool might do with it.
Integration guardrails are rules that sit between a permission and its use. They state what each permission is for, list the exact changes a tool will ever make with it, require a person's approval before any change, and record every change so it can be reviewed. They turn "this app can write to my site" into "this app can publish this approved page, and here is the log".
Proofsource keeps one registry of every permission it asks for, the feature that uses it, and, for anything that can change something in your tool, the only actions it takes. A test fails the build if a new permission is added without such an entry. At run time, a write that is not listed fails closed before your tool is called. Keys are sealed, writes are logged, and when a tool's access changes, Proofsource asks you to reconnect or update permissions instead of failing quietly.
How it works
Every permission Proofsource asks for has a stated use, writes happen only after approval and only in listed ways, and every write is logged.
You grant access
Connect a tool through its own consent screen; Proofsource asks for the permissions its features need, each with a stated use.
Keys are sealed
Tokens and keys are encrypted at rest and never shown back.
Approval before any change
A write needs a person's yes on that fix, or your Autopilot setting.
Only listed writes
If an action is not on that tool's list, it is refused before the tool is called.
Every write is logged
The fix's timeline and the org's audit log show who approved, what was written and where.
See it in the product
Screens from the Proofsource app, drawn with sample data for an example brand.
- driffle.ai
- blog.driffle.ai
- docs.driffle.ai
| When | Who approved | What | Where |
|---|---|---|---|
| Oct 31, 11:40 AM | Maya | Published 'Driffle vs Otter' | WordPress |
| Oct 30, 4:02 PM | Autopilot (your setting) | Opened pull request #14 | GitHub |
| Oct 29, 9:15 AM | Sam | Sent the weekly summary | Slack |
| Oct 28, 2:30 PM | Priya | Published 'Pricing FAQ' |  Webflow |
| Connection | State |
|---|---|
| GitHub | Reconnect needed |
| WordPress | Connected |
| Slack | Connected |
 Bing Webmaster Tools | Connected |
Every capability, live today
6 shipped capabilities behind integration security and guardrails, each in the product now.
Listed changes and reconnect prompts
Each kind of change Proofsource may make in a connected tool is listed; anything else is refused. When access changes, a clear Reconnect needed state offers Connect again and Update permissions.
Encrypted connections and private proof archive
Connection tokens and keys are encrypted at rest, and proof screenshots are kept in private storage with short-lived download links.
Outbound host allow-list
Your org lists the hosts Proofsource may call.
Sign in your way
Org-level single sign-on with OIDC and SAML 2.0, Google sign-in, or an email code. When connecting a tool, verify with an email code or Continue with Google, with a work-email check before scans.
Re-confirm identity for risky actions
Before a destructive or credential-granting action, you re-confirm your identity and get a short-lived approval.
Safe fetching and clean logs
Every server fetch of a URL you supply goes through a guard that blocks requests to internal addresses, and credentials are removed from text before it reaches logs or run records.
Who it is for
Know exactly what the tool can do
Each connection lists its permissions and the only changes made with them.
Sign-in your way
Use SAML 2.0 or OIDC single sign-on, or Google sign-in; there are no passwords to manage.
A record of every change
Audit who approved each write, what was written and where.
Earn client trust on access
Show clients the guardrails before they connect their CMS or repo.
Why it matters
Fails closed
An unlisted action is refused before your tool is ever called.
Approval-gated
Nothing changes in your tools without a yes or your own Autopilot setting.
Fully logged
Every write appears on the fix and in the audit log.
No passwords
Single sign-on, Google sign-in or an email code; keys stay encrypted.
Google AI OverviewsGoogle AI Mode
Integration security and guardrails: Proofsource and other tools
Enterprise controls are common across AI visibility platforms; here is what each one's own pages list.
| Capability | Proofsource | Profound | AthenaHQ | Scrunch | Peec AI | Otterly.AI |
|---|---|---|---|---|---|---|
| Single sign-on | YesSAML 2.0 and OIDC, plus Google sign-in. | YesEnterprise; per-organization Okta sign-in linksSource | YesSAML and OIDC on Enterprise; Google and Microsoft OAuth on StarterSource | YesGoogle SSO on all plans; SAML/OIDC on EnterpriseSource | YesSSO on EnterpriseSource | YesSSO on EnterpriseSource |
| Central handling of connection keys | YesKeys encrypted at rest, read only by the listed call. | YesSecret Manager stores API keys centrallySource | Not listed | Not listed | Not listed | Not listed |
| Role-based access | YesApprovals and writes tied to named people in the audit log. | YesRole-based access and SCIM provisioningSource | YesRole-based access controlSource | YesRBACSource | YesRole-based accessSource | YesRead-only viewer roleSource |
| Listed writes per connected tool | YesOnly listed actions run; others fail before the tool is called. | Not listed | Not listed | Not listed | Not listed | Not listed |
| Audit log of changes | YesEvery write is logged against a named person | Not listed | YesEnterprise onlySource | Not listed | Not listed | Not listed |
| Google sign-in | YesLog in with Google, and continue with Google on connect | Not listed | YesStarter planSource | YesAll plansSource | Not listed | Not listed |
Where each of them shines
Mature enterprise controls, including SCIM, RBAC and a Secret Manager. Compare in full
SSO options from Google and Microsoft to SAML and OIDC.
Google SSO on every plan and RBAC for enterprise teams. Compare in full
Role-based access with a clear company-wide members view. Compare in full
Questions about integration security and guardrails
What can Proofsource change in my connected tools?
Only the actions listed for that integration, such as publishing a fix page you approved or opening a pull request. Anything else is refused before your tool is called.
Does Proofsource change things without asking?
No. A write needs a person's yes on that fix, or your own Autopilot setting, which records that approval on the step.
Where can I see what Proofsource did?
On each fix's timeline and in your org's audit log, with who approved, what was written and where.
How are my tokens and keys stored?
Encrypted at rest, never shown back, and read only by the code that makes the listed call.
Does Proofsource support SSO?
Yes. Org-level single sign-on with SAML 2.0 and OIDC, plus Google sign-in. Proofsource never uses passwords; otherwise you sign in with an email code.
What happens if I revoke access in a tool?
Proofsource shows Reconnect needed and offers Connect again or Update permissions, instead of failing silently.
Can I limit which sites Proofsource calls?
Yes. Your org can keep a list of hosts Proofsource may call on its behalf.
How is this different from Profound's enterprise controls?
Profound offers strong enterprise controls, including SCIM and a Secret Manager. Proofsource adds a per-integration list of allowed writes that fails closed, with every write logged on the fix.
Keep exploring
Try it on your own brand.
Proofsource is live: scan your brand and see integration security and guardrails at work with your own answers, competitors and sources.
Google AI OverviewsGoogle AI Mode