It could be characterized as a hack, but adding a trigger to the relevant msdb system tables might get you what you need:

USE msdb

GO

IF OBJECT_ID(N'dbo.sysjobs_update') IS NOT NULL

DROP TRIGGER dbo.sysjobs_update;

GO

CREATE TRIGGER dbo.sysjobs_update ON sysjobs

FOR UPDATE

AS

BEGIN

SET NOCOUNT ON;

-- send out alert email

EXEC msdb.dbo.sp_send_dbmail

@recipients = 'email@domain.com',

@body = 'Test',

@subject = 'sysjobs has changed';

END

GO

After adding this I actually received multiple emails when creating a new job using SSMS even though I would have expected 0 so you may need to provide for those cases when the GUI or system procs touch the system tables multiple times or in ways that are irrelevant to your auditing goals.

Standard disclaimer: this approach may be too sketchy for some as it is likely unsupported. For auditing consider whether it should be written to fail the initiating operation if the audit operation fails. Before adopting consider the implications when it comes time to apply patches or migrate the instance.

Another option might be to take copies of the tables from 'the secure sql server' you mentioned, do a diff and email if anything has changed. However that leaves the door open for a change, then changeback, in between snaps.