permit 10.0.23.44permit 10.65.23.0/24deny all

The router will look at the IP address of every incoming request, and run it through those rules in sequence. If the request is coming from 10.0.23.44, it will be granted. If it's coming from 10.65.23.99, it will be granted (because that address is within the 10.65.23.0/24 network). Any request from an IP address that doesn't match the first two rules will be rejected. Aside from some tedious details, that's all there is to ACLs!

Understanding this, you can see that in general there are two ways to make Discovery work with such restrictions:

1. Put a MID server at an included IP address. This is by far the most desirable approach. If your enterprise's SNMP ACLs include a network, this could be as simple as finding or installing a server with an IP address in that network. If the ACLs include only individual IPs, then you'll need to find a server with one of those IPs that has enough capacity to handle a MID server. The networking folks often already have a server dedicated to network monitoring; it may be possible for you to install the MID server on that box.
2. Add a new rule to the ACL. Unless your networking team has an automated configuration deployment system, this means someone will have to manually add a new rule to the ACL in every networking device — something most networking teams will not want to do. For this reason, this is the less desirable approach.

One last thought about MID servers placed specially to handle ACLs... If you need such a MID server, it may well be that you'd like that MID server to do nothing else but handle these special cases. That is, you'd like to have another MID server (on some unprivileged box) handle everything it can, and then hand the cases where privilege is needed to the special MID server. This is the kind of thing that Discovery Behaviors do, and I'll describe them in another post...