I presume that you are talking about public, private and protected methods here?
If so, then they don't exist for the purpose of security. They exist for the purpose of making it easier o guarantee that software is properly modularized. (Whether they succeed in that is a debate I'll leave for others. That is, however, the vision of what they are for.)
Suppose that I deliver a library, then I am free to later deliver a different version of the library and change stuff marked as private as much as I want to. By contrast if I had not marked that stuff private, then I would be unable to change any internals of my software because someone, somewhere, is probably accessing it directly. Sure, in theory it is their fault for not using the documented API. But the client will perceive it as my fault that my software upgrade broke their software. They don't want excuses, they want it fixed. But if I don't let them have access to begin with, then my API is exactly the public methods that I intended to be my API and the problem is avoided.
The second most likely thing that you could be talking about is Java's security model. If you're talking about that, then the reason that it exists was that the original vision for Java involved people sending possibly untrusted applets to work interactively inside of third party programs (eg browsers). Therefore the security model was meant to give users some protection against malicious applets. Therefore the security threat to worry about and protect against is untrusted applets trying to interact with other software that might be loaded.