I'm not sure there's a "usual" answer to this question across all CEP engines. CEP engines are really not at all uniform in the services they provide.
You tagged this question with "streambase", so I can talk about that some. The StreamBase CEP runtime has support for user authentication when creating a client connection to a server to dequeue tuples from output streams. People typically hook this up to their local LDAP or AD server.
That said, there's no per-tuple dequeue authorization/entitlements enforcement mechanism in the StreamBase CEP runtime, at least as of the current release (7.3).
So, when StreamBase users want per-tuple entitlements enforcement, we usuallygude them toward building that in at the application layer, or use some other piece of available infrastructure. For example, rather than using native StreamBase Client connections, use an adapter to something like TIBCO EMS or IBM MQSeries and use the per topic/queue entitlements there to restrict access. Or as another example, have the StreamBase server send back a token to an authenticated user after connection, and use that token as a key for entitlements checks on the client side against LDAP using a dequeue interceptor.
Or, as you say, use your own services layer.
There's another example of "Poor Man's Entitlement Service" on the StreamBase Component Exchange. Search for "StreamBase Entitlements". This uses an in-memory or JDBC database to store users, roles, and entitlements and applies them on the server side with an efficient runtime entitlements checking mechanism. But there's no strict runtime restriction on the connections with this; it's just an example of implementing entitlements functionality with a nice UI. The clients voluntarily respect the restrictions, which is probably not what you were asking for.
Disclosure/Disclaimer: I am an employee of TIBCO Software, Inc. Opinions expressed here are my own and not TIBCO's.