Connection denied — what it means
If you've hit a "connection denied" message, it's worth understanding that this is Blacksands working as intended, not a malfunction. This article walks through the fail-closed model and what to check.
Fail-closed, by design
Blacksands' Authorizer plane is built to default to denial. If there's no valid certificate presented, or no explicit grant covering the attempted connection, the answer is no — not "allow and log a warning," not "allow with reduced trust." This is a deliberate security property: in a system built around least-privilege, ambiguous or incomplete authorization should never resolve to access. A connection denied message means the system correctly refused to let something through that it couldn't fully verify — which is exactly what you want it to do.
What to check, in order
When you hit a denial, walk through these in order — most denials trace back to one of the first two:
- Is there a valid certificate? Confirm the connecting identity has a current, non-expired, non-revoked certificate. See Certificate errors and how to fix them if not.
- Is there an active grant? A valid certificate proves who is connecting, but it doesn't by itself authorize where they can go. Check the Manager console (see Understanding the admin console) for whether a grant exists between this identity and the destination, and confirm it hasn't been revoked (see Granting and revoking access).
- Is the scope correct? For Bursar-brokered agent access in particular, a grant might exist but be scoped more narrowly than what's being requested — for example, a read-only grant against a request that requires write access. See Understanding agent identities and scoped access.
- Is the destination itself reachable and correctly registered? Occasionally a denial traces back to the destination app or service not being correctly onboarded, rather than an access-control problem at all.
When it's not a bug
If, after checking all of the above, everything looks correctly configured and the connection is still denied, it's worth treating that as a signal rather than a nuisance — a persistent, unexplained denial can indicate a genuine attempted access outside of policy, which is exactly the scenario fail-closed design exists to catch. Review the relevant audit trail or ledger entry for the attempt before assuming it's purely a configuration issue.
Getting help
If you've worked through the checklist above and are still stuck, see Contacting support.