The best guard against unintended uses that hamstring the maintenance of the library is the good old opaque handle:

   typedef struct foo_struct *foo;

   foo foo_make();
   void foo_destroy(foo);
   void foo_frobnicate(foo, int how);

The client executables have no idea how big a foo object is, or what alignment requirements are, let alone what its members might be. The client executables don't control the allocation, construction, clean-up, freeing, or anything else.

The programmers who use this cannot just edit a header file to gain access to something; the don't have a header file which tells them anything. They could reverse engineer the data structure, but to thwart that, you could scramble the order of the structure members with each new release of the component, so their hack wouldn't be backward or forward compatible.