Yep, It's definitely in the path. I've tried it with and without the full path in the command line. In my haste in posting yesterday.
I forgot to mention that FTP users seem to have no problem here. I'm using vsftp as the server software. All instances of the at command are spawned as the user ftp-files, an internal user with shell privileges. Users that access the site via https however spawn all processes as the user they login as. I.E. external users with no shell privileges. Again the weird thing is that the immediate removal works at doesn't. Both means of access trigger the same script file, the only difference is the user name.
I've also noticed that depending on whether or not I use sudo for the at command itself the user under which it's spawned will change as well.
If nothing else, I've at least got to look forward to the "Brick Wall" until I get this figured out.
-----Post Update-----
It may not be right, but I've found a work around.
I had to call the script that spawns the at command via sudo. For whatever reason calling the at command directly wouldn't work sudo or not. I even tried just echoing text to a file. Nothing... Nothing in /var/log/anything. Just nothing.
Backing up one script and making the sudo call there worked. Although I still want to figure out why the direct call didn't work, I'll have to put it aside for now and finish my task.
Thanks for the input.