You might want to double-check what the MSDB database thinks the backup history is. Comment IN or OUT whichever "bits" you need
SELECT TOP 1000
-- , *
FROM msdb.dbo.backupset AS BS
LEFT OUTER JOIN msdb.dbo.backupmediafamily AS BMF
ON BMF.media_set_id = BS.media_set_id
AND BS.database_name = DB_Name() -- Current DB
-- AND BS.database_name = N'MyDatabaseName' -- Specific DB
-- type : D=Full, I=Differential, L=Log, G=FileGroup, V=VerifyOnly
-- AND BS.type='L'
-- AND BS.backup_size > 10000000
-- AND BS.backup_start_date > '20001231 01:23'
ORDER BY BS.backup_start_date DESC, BS.database_name, BMF.family_sequence_number
I agree the most likely "unexpected backups" would be from a Tape Backup which has an "Agent" on your particular server which is making the backups. If that is what you have and database backups to Files are NOT being backed up to Tape then I would want to be sure that your recovery route is "sound". You need to be able to get the Agent installed on a brand new machine (after a disaster) and then recover, direct from tape, using the agent.
Whereas if you put Backup Files on Tape then all you need to do is get the file back, somewhere, and transfer that file to the new server, and then restore it. Much better chance of success without "aggro" IMHO.
If your Backup Files ARE being copied to tape I'd get rid of the Agent backup direct to tape - high probability that it takes a Full backup at an unexpected time which wrecks your Chain for DIFF backups (and would require getting the Tape loaded, and Restored in order to get the DB backup, rather than just being able to restore "Latest FULL, DIFF and LOG files" which you have "lying around on disk for just that eventuality". Dunno about you, but here getting a tape loaded for a restore "takes some time" compared to any backup files that I have ready-access to on the server.