Update:Added emphasis to highlight that the source is unavailable.

Whilst I agree it is the procedures that need fixing, I have also had the unhappy experience of working at a place where 'rules is rules', no matter how silly.

The best option I can come up with is to create a DLL/SO using XS that can be accessible in binary form only, that has an entrypoint that makes the connection to the DB and returns the DBI handle. The DLL/SO contains the user/pass encrypted. When called, the entrypoint decryptes the user/pass, evals code that loads the appropriate modules and calls the connect and returns the dbh.

Here simulated using Inline::C and crap encryption, just for a flavour of the sort of thing I mean. (Note: I do not have a user called root with a password secret, hence the error):

#! perl -slw
use strict;
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C',  NAME => 'secret', CLEAN_AFTER_BUILD => 0;

static char code[] = "\
use DBI;\
use DBD::Pg;\
DBI->connect(\"dbi:Pg:database=test;\", 'EXXC', 'DRTERC' )\
";


static char *user = code + 59;
static char *pass = code + 67;

SV *getDBH ( SV *dummy ) {
    int i;

    for( i = 0; i < 4; ++i ) user[ i ] ^= 55;
    for( i = 0; i < 6; ++i ) pass[ i ] ^= 55;

// The next line is (obviously) for demonstration purposes only!!!
    printf( "'%s'", code ); 
    return eval_pv( code, 1 );

}

END_C

print getDBH( 'fred' );

__END__
C:\test>secret
'use DBI;use DBD::Pg;DBI->connect("dbi:Pg:database=test;", 'root', 'se
+cret' )'
     DBI connect('database=test;','root',...) failed: 
     could not connect to server: Connection refused (0x0000274D/10061
+)
        Is the server running on host "???" and accepting
        TCP/IP connections on port 5432? at (eval 10) line 1
Use of uninitialized value in print at C:\test\secret.pl line 29.

Attempt to free unreferenced scalar: SV 0x411b660, Perl interpreter: 0
+x29fb8.
[download]

Written in XS with only the resultant dll accessible to the user (execute only if that possible on your system). And using a better encryption, probably on the whole connection string rather than just the user/pass, this would defeat most casual attempts at discovery.

You might also require that the user pass in some arbitrary (but checked) token into the api--say '811f8915e99fbed4b814174de746d0485bf63f8705a5b7bfc0b178c525798a49' or similar that you give the programmer(s). That might divert attention from the real location of the relevant information for a while. Provided that they are not also PM users :)

Or you might use the token passed as a part of the decryption process, thereby allowing you to embed the credentials of several accounts and have the token also select which set of credentials are used for the connection.