@agardner how are you going to trigger the script to run?
Does this script need to be divorced from your Jamf Pro environment? What I mean is, is it a requirement that the script be run outside of jamf entirely (standalone)? If not, why not place it in Self Service? That's kind of what it's for - to allow end users without admin rights to run commands or installers with admin rights.
If the above isn't an option, there are some other options, but none are that great. You could, for example, use an expect block to pass the admin account password to the prompt, but this is very insecure. Especially if you plan on just giving this script in plain text to your users. They would be able to open the script in a text editor and would see the password in plain text, especially since you aren't pairing it up with a policy. If you were, the policy could send the password down to the script as a parameter so it wouldn't appear right in the script itself.
Another option would be to deploy a special LaunchDaemon that could watch for a file (WatchPath) and execute the script file or some other command when it gets triggered. Your 'end user' script could place something in the trigger file to make the LaunchDaemon do it's thing, as root. I've done things like this before as a type of workaround, but it's far from ideal, and I'll even say a little fragile to be honest.
Lastly, there would be a way to do this using an AppleScript, since AS has the ability to do commands with administrator privileges, but the script would still need to contain your local admin name and password. The main difference is, AppleScript lets you compile scripts as Run Only, meaning the end user can't open it up into the Script Editor or another application and read it. That doesn't mean it's impossible to get information out of the script, but it makes it considerably harder at least. So it's still not completely secure, but far better than using an expect block.
The command would look something like this in your AppleScript:
do shell script "shell command goes here" user name "admin_account" password "password123" with administrator privileges
If you can post any more details about what the script or the sudo command is doing, there may be other options that will come to light.
All that being said, I still think your best option would be to do this from Self Service if it's an option at all.
If you are running locally on the machine you can add a line to /etc/sudoers to allow the command you need, I do this with our printer unpausing script
BW-WKSDIGPR-99:login_extra admin$ sudo tail -1 /etc/sudoers
%everyone ALL=(ALL) NOPASSWD: /usr/sbin/cupsenable
BW-WKSDIGPR-99:login_extra admin$ cat /Applications/unpause_printers.command
sudo /usr/sbin/cupsenable `lpstat -t | grep disabled | awk '{print $2}'`
